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This  work  is  concerned  with  the  automatic  derivation  of  code 
generators.  The  followino  results  are  presented: 

1,  a  tundam.ental  model  for  describing  machines 

2,  code  derivation  algorithms  for  translating  language 
operations  Into  near-optimal  target  machine  code 
seguences 

3.  a  procedure  for  detecting  a  larnp  class  of  machine- 
dependent  optimizations 

4.  technigues  tor  generating  code  generators 

The  mrich  1  ne- i ndependent  code  derivation  algorithms  represent  the 
main  work  of  the  thesis.  A  prototype  code  generator  generator 
was  implemented  to  demonstrate  the  feasibility  and  practicality 
of  the  algorithms  proposed. 
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I,  luxaouucxiuii 


1  •  t . 

In  the  past  decade  there  has  been  an  increasinq  interest  in 
automatic  generation  of  combilers,  Most  of  the  reasons  for  this 
interest  are  obvious.  As  new  machine  architectures  rapidly 
evolve  and  higher-level  programming  languages  are  introduced, 
reducing  the  effort  to  construct  compilers  becomes  clearly  desir¬ 
able,  Of  additional  Interest  is  the  production  of  compilers 
which  generate  high  quality  code. 

Unfortunately,  automation  of  the  entire  compiler  generation 
process  has  not  yet  been  realized.  Much  progress  has  been  made 

Aith  respect  to  automating  the  process  of  parsing  program  text 

into  internal  representations.  Only  until  recently  has  some  lim¬ 
ited  success  been  achieved  with  automating  the  last  phase  of  com¬ 
pilation:  transforming  the  internal  representation  Into  instruc¬ 

tions  tor  the  target  machine  (code  generation).  Major  reasons 
for  this  lack  of  success  can  be  attributed  to  the  following: 

1)  inadequate  formalization  of  machines 

2)  inadequate  methods  for  deriving  high-quality  machine- 
independent  code  sequences 

Recent:  >ofk  in  the  area  of  machine  formalizations  has  yielded 
some  optimistic  results  ( Csooeun  1 1 9  /  8 1  ,  Cat  t  e  1 1  1  1  97  8 1  ) ,  Most  of 
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the  work  dealing  with  machine-independent  code  generation,  how¬ 
ever,  has  been  notably  unsuccessful  in  terms  of  practical  appli¬ 
cability. 

The  maior  work  of  this  thesis  is  to  study  and  propose  solu¬ 
tions  for  the  machine- 1 ndependent  code  generation  problem,  A 
simple  but  extensible  automatic  code  generator  model  will  be 
presented.  The  model's  purpose  is  to  provide  a  working  founda¬ 
tion  upon  which  machine  code  sequences  can  be  derived  using  the 
algorithms  developed  and,  addl t ional ly ,  to  propose  a  new  approach 
to  code  generator  oeneration  aimed  at  improving  code  generator 
quality.  Due  to  the  time  limitations  imposed  upon  this  work,  the 
model  presented  is  not  complete.  However,  it  has  been  kept  as 
general  as  possible  and  extensions  to  the  automatic  code  genera¬ 
tor  are  discussed  in  a  separate  chapter,  A  working  prototype  has 
been  implemented  to  demonstrate  the  feasibility  and  practicality 
of  the  code  derivation  method  developed,  Tt  should  be  stressed 
that  testing  of  the  mach Ine-independen t  code  generation  algo¬ 
rithms  proposed  is  the  sole  purpose  of  the  prototype  and  It  is  in 
no  way  intended  to  be  a  production  Implementation, 


1,2.  aiLai:xJL£iiL 

In  chapter  2,  the  major  obstacles  which  have  hindered  code 
generator  generation  are  examined,  A  survey  of  some  of  the  more 
recent  work  pertaining  to  automatic  code  generation  is  provided 
so  that  the  reader  may  obtain  some  insight  regarding  the  current 
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state  o£  affairs.  Factors  to  be  considered  for  generating  near 
optimal  code  seouences  and  the  general  approach  that  will  be 
taken  with  regards  to  code  aenerator  generation  are  outlined. 

Chapter  3  is  concerned  with  the  automatic  derivation  of  code 
generators.  ACG  (an  Automatic  Code  Generator)  is  introduced.  It 
uses  input  descriptions  of  both  the  target  machine  and 
intermediate-level  language  in  order  tc  produce  code  templates 
for  each  language  operator.  These  templates  can  then  be  directly 
utilized  by  a  table-driven  code  generator,  or  alternatively, 
applied  towards  the  construction  of  a  non  table-driven  code  gen¬ 
erator.  Methods  of  organizing  template  production  and  current 
limitations  of  ACG  are  discussed. 

Chapter  4,  the  core  of  the  thesis,  proposes  algorithms  for 
deriving  the  code  templates  output  by  ACG,  The  task  involves 
finding  the  best  target  machine  instruction  sequence  for  each 
semantically  defined  language  operator.  Established  methodology 
from  the  field  of  artificial  intelligence  will  be  used  to  make 
the  search  for  such  code  sequences  both  feasible  and  practical. 
Ideally,  optimal  code  is  desired.  However,  the  derivation  of 
optimal  code  is  an  hP-compiete  problem,  and  so  near-optlmaiity 
must  be  established  as  the  goal  of  this  work.  An  evaluation  of 
the  berformance  of  the  algorithms,  which  were  tested  using  the 
working  prototype,  is  provided. 

Chapter  b  is  devoted  to  discussing  the  maior  extensions 
required  for  converting  ACG  Into  a  full-scale  model.  For  all  of 
the  extensions  proposed,  implementation  suggestions  are  offered. 
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Chapter  6  summarizes  the  research. 

In  appendix  A,  three  diverse  machine  models  are  presented: 

Machine  A  -  a  sinole  accumulator  machine.  In  which  use  of 

the  accumulator  is  required  for  ail  computations 

Machine  H  •  a  mul t i -req J s ter  machine,  where  placement  of 

source  operands  in  registers  is  required  for 
computations 

Machine  C  -  a  multi-register  machine,  hut  computations  are 

permitted  using  either  registers  or  memory 
locations 

References  to  these  machines  are  made  in  examples  throughout 
chapter  4  of  the  thesis. 

Machine-independent  code  generation  examples  are  provided  in 
appendix  B.  Using  the  three  machine  models  described  in  appendix 
A  and  a  list  of  non-trlvial  goals  for  which  code  is  to  be  gen¬ 
erated,  the  working  prototype  was  employed  to  find  the  best  code 
sequence  for  each  goal  for  each  machine.  The  code  sequences 
illustrated  represent  the  solutions  obtained  after  simulated 
compile-time  register  and  temporary  storage  allocation  have  been 
performed. 

Appendix  C  provides  code  template  examples.  These  templates 
denote  the  actual  format  of  the  output  obtained  from  ACG, 
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2,  IWu  COaL  GEEEEilXQa  aEJilEEAXlLm  EaQaLEM 


2.1.  auz:&o;ia 

An  automatic  code  qenerator  takes  a  target  machine  descrip¬ 
tion  and  possibly  other  information  as  input.  It  provides,  as 
output,  all  the  necessary  information  required  at  compile-time 
for  converting  intermediate-level  language  (IL)  programs  into 
code  sequences  for  the  target  machine.  The  output  obtained  will 
normally  be  In  the  form  of  code  templates,  permitting  direct 
utilization  by  a  table-driven  code  generator,  E:ach  template 
specifies  compiler  actions  and  machine  instructions  to  generate 
when  a  particular  IL  language  construct  is  encountered  at  code 
generation  time.  Figure  I  graphically  portrays  the  relationship 
between  automatic  code  generator  components  and  compilation. 

Automatic  code  generator  use  can  be  extended  beyond  produc¬ 
tion  of  templates  for  IL  operators.  Additionally,  the  code 
derivation  capabilities  can  be  effectively  used  to  derive  other 
machine-dependent  software,  such  as  interperter  run-time  routines 
or  source-language  support  functions. 


2,2.  a&auli:em£at5.  dad  Qb»sXdcles  Eacauataoad 

The  following  attributes  are  of  Importance  to  any  code  gen¬ 
erator  qenerator; 

1 )  a  high  degree  of  machine-independence 
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Figure  1!  Relationship  of  automatic  code  generator  components 
and  compilation. 


2)  the  caprabillty  to  derive  high-quality  machine  code 


sequences 

3)  the  capacity  to  adequately  deal  with  special-case 
conditions  determined  by  the  charact er ist ics  of  the 
target  machine  instruction  set 

The  degree  of  machine-independence  directly  relates  to  the 
classes  of  machines  that  can  be  handled.  The  format  of  the 
machine  description  should  not  only  permit  a  wide  variety  of 
existing  machines  to  be  accurately  specified,  but  ideally,  allow 
for  the  representation  of  new  machines  as  they  are  developed. 
The  key  to  accomplishing  this  feat  Is  to  maintain  generality 
where  possible.  For  instance,  user-definition  of  abstract  data 
types  is  preferable  over  user-selection  of  ore-defined  data 
types.  At  the  same  time,  however,  a  strict  and  formal  manner  of 
specifying  machines  is  necessary  to  make  it  feasible  to  automati¬ 
cally  generate  code  generators.  This  f ormal 1 zat ion  has  the 
effect  of  restricting  the  classes  of  machines  that  can  be 
accepted.  Unfortunately,  a  compromise  between  generality  and 
feasibility  is  inevitable  for  any  code  generator  generator. 

The  derivation  of  hidh-guality  machine  code  sequences  is  a 
reouirement  that  is  obvious.  The  templates  produced  dictate  the 
code  sequences  that  will  be  generated  by  some  compiler.  If  the 
templates  themselves  contain  sub-standard  quality  code  sequences, 
then  the  compiler  using  these  templates  will  itself  generate  poor 
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code . 


Consequently,  the  purpose  of  the  code  generator  generator 


will  have  been  defeated. 

Ideally,  optical  code  sequences  are  desired,  Hovi'ever,  the 
derivation  of  such  is  an  MP-compiete  oroblen  (Wuit  [19751;  Aho, 
vJohnson,  U  I J  man  T 1  97  7 1  ;  SzymansKi  1 1 97H  ]  )  and  so  optimality  can¬ 
not  be  guaranteed,  Civen  the  semantic  definition  of  some 
language  operator,  it  may  be  possible  to  derive  a  better  code 
sequence  by  finding  a  different  semantic  interpretation  of  that 
operation.  However,  the  unsolvability  of  program  equivalence 
states  that  no  set  of  rixioms  can  express  all  the  arithmetic 
equivalences  of  an  operation.  Consequently,  one  cannot  secure 
with  any  certainty  the  semantic  definition  yielding  the  optimal 
code  sequence.  Any  code  generator  generator  must  therefore 
establish  near-opt imal i ty  as  Its  goal. 

Finding  the  best  code  seouenco  is  a  non-trlvial  tasK  as  the 
selection  may  have  to  be  made  from  amono  a  domain  consisting  of  a 
vast  number  of  code  sequence  possibilities.  Using  the  exhaustive 
approach,  whereby  every  possibility  is  investigated  to  ensure 
finding  the  best  solution,  is  Impractical  In  the  sense  that  the 
duration  of  the  search  may  extend  for  a  combi natorial ly  long 
period  of  time.  Sophisticated  techniques  are  required  to  minim¬ 
ize  search  activity  without  affecting  the  quality  of  solution 
Obtained,  Devising  methods  of  extracting  the  best  code  sequence 
within  reasonable  time  spans  is  a  challenge  that  has  been  met 
with  limited  success  onlv  until  recently. 

Given  suitable  methods  for  deriving  code  sequences  for  TL 
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operators,  the  task  of  an  automatic  code  qenerator  is  not  com¬ 
plete,  Supposin^i  optimal  code  could  be  guaranteed  tor  each  of 
the  operators,  the  code  qenerator  using  the  resultant  templates 
will  not  neccesarily  generate  optimal  code.  Another  set  of  tem¬ 
plates  are  required  for  handling  special-case  conditions.  These 
special-cases  are'  determined  by  the  character i st ics  of  the  target 
machine  instruction  set.  They  denote  instances  where  code  optiml- 
zations  are  possible,  with  respect  to  the  general-case  code 
sequences,  when  ci rcumstances  permit.  Two  classes  of  special- 
case  conditions  are  prevalent: 

1  )  special-cases  involving  operand  information 

2')  snecial-cases  Involving  operator  combinations 

The  first  type,  those  Involving  operand  information,  pertain 
to  cases  where  optimizations  exist  when  one  or  more  of  the 
operands  of  an  IL  operation  are  known  to  be  eoual  to  certain 
values  or  addressable  at  specific  machine  locations,  A  simple 
example  will  be  given.  Suppose  a  machine  has  an  ’'add”  and  an 
"increment"  instruction,  with  "increment"  being  the  faster  in 
terms  of  execution  speed.  A  special-case  template  should  be 
created  for  tne  "increment"  instruction.  It  would  then  be  used 
whenever  an  I L  add-operation  is  encountered  with  one  of  the 
operands  having  a  value  within  the  increment  range  permitted. 

The  second  type  of  special-case  conditions  are  those  involv¬ 
ing  Uj  operator  combinations.  In  tnese  cases,  the  best  code  for 
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the  operator  conninatlon  is  not  the  ap.irendte  sequence  romorislnq 
the  Individual  code  sequences  of  the  operators  involved.  For 
instance,  consider  the  foiiowinq: 

are  machine  Instructions 
{nPl,fjP2^  are  II,  ooerators 

TFiMPLATFlGPl)  =  hi 
TFMPT,ATF(CiP2  )  =  h? 

and  M3  Is  semant j ca 1 ly  equivalent  to  the  instruction 
sequence  mi;m2 

Given  the  operator  combination  nPl;nP2  at  compi 1 e-t ime ,  the  tern* 
plates  dictate  qeneratlnq  the  code  sequence  Ml; M2  although  the 
single  instruction  Mi  js  a  better  choice.  This  phenomenon  will, 
henceforth,  be  referred  to  as  compile-time  code  degradation.  The 
solution  to  the  above  problem,  of  course,  is  to  create  a 
special-case  template  for  that  particular  operator  combination: 

TF.MPLATFCUPl  ;0P2)  =  Mi 

It  is  essential  that  code  generator  generators  not  ignore 
treatment  of  special-case  conditions.  Proper  treatment  ensures 
the  derivation  of  "smart"  code  generators,  and  conversely,  lack 
of  treatment  will  undoubtly  result  in  code  generators  that  pro¬ 
duce  poor  quality  code.  Unfortunately,  this  aspect  of  code  gen¬ 
erator  generation  has  been  virtually  unstudied.  First,  methods 
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are  required  to  automat ically  determine  what  IL  constructs  con¬ 
stitute  special -cases.  Second,  it  is  necessary  to  limit  treat¬ 
ment  to  only  those  cases  of  greatest  importance.  An  vast  number 
of  operator  combinations  imply  the  possibility  of  a  very  large 
number  of  special-cases .  Not  only  would  it  he  infeasible  to 
check  as  many  operator  combinations  as  possible,  but  the  resul¬ 
tant  code  generator  would  be  highly  inefficient  in  terms  of  speed 
it  most  of  its  time  is  soent  checking  endless  lists  of  special- 
cases  instead  of  generating  code.  Compile-time  code  degradation, 
resulting  from  special-case  operator  combinations,  is  a  problem 
common  to  all  code  generators.  However,  smart  compilers  allevi¬ 
ate  the  problem  by  giving  special  consideration  to  only  those 
cases  occurring  most  frequently  or  those  tor  which  substantial 
optimizations  are  possible.  Therefore,  given  a  means  of  detect¬ 
ing  spec ia 1 -cases ,  further  methods  are  in  order  for  determining 
which  of  those  cases  justify  special  treatment. 


2 .  d .  Cux.£.&al  J.giaXen£utatlaa& 

The  basis  for  code  generator  generation  was  provided  by  Bell 
and  Newel  1 f 1 97 1 J ,  They  proposed  an  ISP  (Instruction  set  proces¬ 
sor)  modPi,  marking  one  of  the  first  more  successful  endeavors  at 
formalizing  machines.  However,  their  intent  was  aimed  at  the 
specification  ot  machines  for  expository  purposes  only.  No 
foret[\ought  was  given  to  use  of  the  model  in  automatic  code  gen¬ 


erator  applicat 1 ons ,  Consequently,  a  more  precise  and  structured 


fTiodel  than  theirs  hec^'ne  necessary  since  the  machine  description 
would  have  to  oe  used  as  a  rldorous  definition  to  some  computer 
proqram , 

Since  the  contribution  of  Bell  and  Newell,  there  has  been 
little  work  of  any  major  success  in  the  area  of  automatic  deriva¬ 
tion  of  code  generators.  Most  of  the  work,  some  of  it  relating 
indirectly,  is  discussed  in  Cattell  1  1  9  77  1  ,  However,  three  recent 
code  generator  generator  models  of  Interest  to  this  work  will  be 
surveyed  here, 

Fraser[1977i  developed  what  he  called  a  "human-knowledge- 
based"  code  generator.  Basically,  an  ISP-like  description  con¬ 
stituted  the  input  to  the  model  and  pre-programmed  knowledoe 
would  be  utilized  to  derive  the  necessary  target  machine  code 
sequences.  The  built-in  orogramming  knowledge  defined  the  common 
cases  recognized  by  the  system.  These  cases  would  then  be 
pattern-matched,  if  possible,  with  the  available  machine  instruc¬ 
tions,  For  instance,  the  system  recognized  and  would  check  for 
machines  with  conditional  skip  architect ures ,  Fraser's  work  took 
on  a  less  formal  approach  to  code  generator  generation  as  it  was 
based  on  the  assumption  that  most  machine  architectures  are  simi¬ 
lar  in  design.  The  advantages  of  the  human-knowledge-based 
approach  lie  in  its  practicality.  The  built-in  programming 
knowledge  not  only  permits  quick  and  efficient  derivation  of 
machine  code  sequences,  but  also  provides  adequate  treatment  for 
special-case  conditions.  Both  factors  present  potentially  com- 
binatorially  explosive  situations  under  a  more  formal-based 
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approach . 


In  addition, 


Fraser  does  present  some  evidence  that 


the  amount  of  new  prodramminq  knowledqe  that  must  be  incorporated 
in  the  system  decreases  as  machines  of  similar  architecture  are 
added.  Unfortunately  though,  the  built-in  programming  knowledge 
does  render  the  system  dependent  upon  a  certain  class  of 
machines.  The  severity  of  this  drawback  is  further  increased,  as 
It  is  now  possible  to  generate  new  and  diverse  machine  architec¬ 
tures  quite  easily  through  both  LSI  technology  and  microprogram¬ 
ming, 

GoguenCl978]  adopted  a  more  formal  approach  to  code  genera¬ 
tor  generation  than  Fraser,  The  bulk  of  Goguen's  work  concen¬ 
trated  on  the  design  of  a  model  permitting  the  specif icat Ion  of 
all  the  components  and  details  of  most  classes  of  machines. 
Using  the  information  obtained  from  the  machine  description,  the 
model's  objective  was  the  production  of  code  templates  to  cover 
all  operand  access  mode  and  data  type  possibilities  for  each  TL 
operator.  At  complle-t ime ,  the  code  sequence  to  generate  for 
some  operator  would  be  referenced  by  means  of  a  three-dimensional 
template  pointer  table  (IL  operator  :  operand  addressing  modes  ; 
operand  types).  The  strengths  of  Goguen's  work  lies  with  the 
machine  formalization  aspect,  where  a  very  thorough  and  precise 
manner  of  specifying  machines  is  presented.  The  weaknesses  con¬ 
cern  the  machine-lndeoendent  code  generation  capabilities  of  the 
model,  A  one-to-one  correspondence  between  machine  instructions 
and  IL  operators  was  assumed.  In  the  absence  of  required  machine 
instructions,  techniques  tor  finding  alternate  code  sequences  was 
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left  as  an  area  for  future  research.  In  addition#  no  treatment 
was  afforded  tor  special-case  conditions, 

A  formal-based  approach  to  code  qenerator  aeneration  was 
also  taken  by  Cat te 1 1  [  1  978 ] ,  However#  unlike  Goquen  who  dealt 
primarily  with  the  machine  f ormal Izat ion  aspect#  Cattell's  work 
concentrated  heavily  on  machine-independent  code  qeneration.  His 
primary  objective  was  the  automatic  derivation  of  best  target 
machine  code  sequences  for  III  operators. 

Cattell's  scheme  for  derivinq  code  sequences  involved  a 
recursive  heuristic  search  in  which  various  transformations  of  an 
operator's  semantics  would  be  attempted  in  order  to  find  the  one 
semantic  definition  that  could  be  best  matched  by  the  available 
machine  instructions,  A  set  of  axioms  defined  the  semantics- 
oreservinq  transformations  that  could  be  legally  performed.  They 
were  used  in  conjunction  with  means-ends  analysis  to  determine 
which  transformations  were  to  be  attempted  durina  the  course  of 
the  search.  Basically,  means -ends  analysis  Involves  deciding  how 
to  get  from  wnat  you  have  (a  given  semantic  definition)  to  what 
you  want  (an  equivalent  definition  expressed  in  terms  of  the 
semantics  of  one  or  more  of  the  available  machine  instructions) 
by  examining  the  difference  between  the  two  and  selecting  actions 
(transformation  axioms)  to  reduce  that  difference.  The  heuristic 
nature  of  the  search  made  this  scheme  practical  by  confining  the 
number  of  transformations  attempted  to  those  that  were  likely  to 
result  in  fayorable  outcomes. 

The  formalization  of  instruction  set  processors  was  also  a 
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topic  ot  Cattell's  work,  although  not  given  treatment  to  the 
extent  Goguen  provided.  It  served  as  the  foundation  for  a  code 
generator  generator  implementation.  The  derivation  of  code  gen- 
rators  involved  the  production  of  three  sets  of  templates. 
First,  general-case  templates  tor  each  Ih  operator  would  be 
created  using  the  code  derivation  scheme  to  find  appropriate  code 
sequences.  The  second  set  of  templates  were  for  operand  target¬ 
ting  purposes  and  used  in  combination  with  the  general-case  tem¬ 
plates  at  compile-time  to  ensure  the  proper  access  mode  tor  each 
operand.  These  templates  would  be  created  by  deriving  code 
sequences  for  constructs  of  the  form  A<-B,  tor  each  possible 
operand  access  mode  combination  A,B,  The  third  set  of  templates 
were  for  special-case  conditions.  Since  no  algorithm  was  devised 
to  au tomat ical ly  determine  what  special-cases  existed,  a  partial 
solution  to  the  problem  was  ottered  by  producing  templates  for 
Individual  target  machine  Instructions,  This,  in  effect,  encom¬ 
passed  the  scope  of  special-cases  that  could  be  directly  matched 
by  single  instructions. 

An  evaluation  of  Cattell's  work  Is  favorable.  no  one-to-one 
cor respondence  between  T i,  operators  and  machine  instructions  need 
be  assumed  and,  in  many  cases,  the  code  derivation  scheme  was 
successful  in  deriving  optimal  sequences.  Of  equal  Importance  is 
the  generality  of  the  model,  permitting  representation  of  most 
classes  ot  machines,  and  the  practicality  of  the  code  derivation 
scheme,  using  heuristics,  to  effectively  deal  with  the  combina¬ 
torial  explosion  consequent  of  a  formal-hased  approach.  However, 
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some  shortcomings  >vlth  resnoct  to  the  code  derivation  sc erne  do 
exist,  in  that,  its  success  is  limited  to  cases  where  only 
minimal  semantic  complexity  is  involved.  The  transtormat lon» 
axiom-based  met^lOd  is  suited  to  the  problem  of  flndinq  code 
sequences  for  low-level  primitives,  where  re-definition  of  a 
primitive  in  terms  of  other  primitive  operator  combinations  is 
necessary  for  derivinn  alternate  code  sequences.  In  cases 
involving  greater  semantic  complexity,  the  scheme  fails  to  keep 
track  of  processor  state  location  values  nor  does  it  recognize 
common  sub-expressions.  As  a  result#  if  a  value  is  required  in  a 
register,  it  will  be  re-loaded  (or  re-ca leu lat ed )  even  if  some 
register  already  contains  that  value.  This  deficiency  can  be 
attributed  to  the  recursive  approach  used  by  the  code  derivation 
scheme,  dictating  the  order  in  which  sub-expressions  are  to  be 
evaluated  and  preventing  adequate  simulation  of  the  processor 
state  location  values  during  the  search. 


2 •4, 

The  previous  section  provided  a  synopsis  of  the  major  work 
to  date  directly  relating  to  code  generator  generation.  Much  has 
still  to  be  accomplished  as  none  of  the  models  described  yet 
qualify  as  production  implementations.  Kfforts  are  currently 
underway  to  improve  the  quality  of  code  generator  generators.  In 
particular,  Cattell's  work  is  being  extended  and  used  in  the  Pro¬ 
duction  Quality  Compi ler-Comp i ler  (PQCC)  project  at  Carneqle- 
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Mellon  Oniversity  ( Wul f f 1 979] ) , 

The  machine-independent  code  qeneration  aspect  warrants  much 
attention,  due  not  only  to  its  importance,  but  also  because  o£ 
the  little  success  obtained  In  the  area*  This  is  evidenced  by 
the  failure  of  Goquen's  model  to  adequately  deal  with  the  problem 
and  Fraser's  somewhat  ad  hoc  solution  tor  derivlnq  target  machine 
code  sequences.  Cattell's  work,  in  contrast,  rates  as  the  first 
real  success  ot  any  type  in  that  area*  In  addition  to  the 
machine-independent  code  generation  problem,  the  detection  and 
proper  treatment  of  special-case  conditions  is  another  facet  of 
code  generator  qeneration  that  has  been  insufficiently  handled. 

This  thesis  is  concerned  with  machine-independent  code  gen¬ 
eration  and  the  treatment  of  special-case  conditions.  The  pri¬ 
mary  objective  will  be  to  derive  algorithms  that  can  successfully 
find  near-optimal  code  sequences  for  semantic  expression  of 
potentially  unlimited  complexity.  The  high-level  code  derivation 
capabilities  will,  in  effect,  also  permit  usage  of  the  algorithms 
for  derivation  of  other  machine-dependent  software.  The  secon¬ 
dary  objective  will  be  the  design  of  a  simple  but  extensible 
automatic  code  generator  model,  abbreviated  by  the  acronym  ACG, 
which  utilizes  the  algorithms  developed  and  also  provides  a  means 
for  effectively  dealing  with  special-case  conditions. 

Factors  pertinent  to  the  issue  of  generating  near-optimal 
code  for  high-level  semantic  expressions  include  the  order  in 
which  sub-expressions  are  evaluated  and  the  proper  utilization  of 


common  sub-expressions 


These  are  of  Importance  to  minimizing 


Intermediate  (temporary)  storaqe  demands  and  avoiding  redundant 
code.  It  would  be  preferable  to  resolve  these  factors  first, 
prior  to  actually  searchinq  for  the  code,  by  restructuring  a 
semantic  expression  to  reflect  the  correct  evaluation  ordering 
and  common  sub-expression  mergers.  Unfortunately,  intermediate 
storage  demands  are  associated  with  Individual  machine  instruc¬ 
tions,  Thus,  the  correct  semantic  restructuring  is  dependent  upon 
the  choice  of  instructions.  Figures  2,  3,  and  4  illustrate  the 
machine-dependent  nature  of  the  problem  by  presenting  a  semantic 
expression  for  which  code  is  to  be  generated  using  only  the 
"add",  "multiply",  and  "move"  Instructions  of  the  three  example 
machines.  In  figure  2,  the  code  sequences 
obtained  by  pattern-matching  instructions  with  the  original 
semantic  expression  are  presented.  Figure  3  gives  the  code 
sequences  obtained  when  common  sub-expressions  are  merged  prior 
to  pattern-matching  instructions.  For  this  example,  code 
improvements  were  recorded  in  only  one  of  the  cases,  actual  code 
deterioration  occurring  in  the  other  two.  Optimal  code  sequences 
for  each  machine  are  presented  in  figure  4,  along  with  the  seman¬ 
tic  restructuring  required  to  yield  each  of  those  sequences.  The 
optimal  semantic  structuring  is  different  for  each  machine. 
Finding  optimal  semantic  structures  in  con:)unction  with  finding 
instruction  sequences  to  pattern-match  an  expression  will  be  the 
objective  of  our  code  derivation  scheme.  To  accomplish  this 
task,  a  non-recursive  heuristic  search  will  be  used  where  nodes 
of  the  search  space  represent  different  states  of  the  target 
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(operands  represented  by 
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ADD  X  <->  ACC<-ACC+X 
NlUL  X  <->  ACCk-ACC^X 
LD  X  <->  ACC<-X 
ST  X  <->  X<-ACC 


ADD  R1,R2  <->  R2<-R2  +  R1  add  X,Y  <->  Y<-Y*t-X 
MUL  P1,R2  <->  R2<-P2*P1  rrul  X,Y  <->  Y<-Y»X 


LD  R1,X  <->  Rl<-X 
ST  R1,X  <->  X<-R1 


(X,Y  denote  any  machine  locations 
RlrP2  refer  to  any  available  registers 
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Temporaries  :  1 


Instructions:  13 
Temporaries  :  3 


Instructions:  7 

Temporaries  :  1 


Figure  2: 


Code  sequences  obtained  by  directly  pattern-matching 
the  given  semantic  expression. 
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GOALS 


A<-A+(B+C)  H<-nf(0»C)  C<-A 


SEMANTIC 
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/  I  \ 
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/  \  /  \  /  \ 
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[21  ,D 
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[  2  1  , 

[01  ,C 

Instructions;  12 
Temporaries  ;  2 


Instructions:  11 
Temporaries  ;  3 


Instructions:  8 

Temporaries  :  2 


Figure  3:  Code  obtained  when  common  sub-expressions  are  merged 
prior  to  pattern-matching  instructions. 
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Figure  4:  Optimal  code  sequences  for  each  machine  and 

corresponding  semantic  restructuring  necessary  to 
yielci  those  sequences. 


machine.  The  non-recur s i ve  approach  permits  proper  handling  of 
common  sub-expressions  and  experimentation  with  different  sub¬ 
expression  evaluation  orderings.  The  heuristics,  of  course,  are 
intended  to  make  the  search  practical  by  llmltlnq  the  number  of 
alternatives  investigated.  Optimizations  involving  re-def inlt ion 
of  semantics  in  terms  of  different  primitive  operator  combina¬ 
tions  will  not  be  covered  in  this  work.  We  feel  Cattell's 
transformation-axiom-based  scheme  successfully  handles  optimiza¬ 
tions  of  that  type.  Simple  operator  transformations  will  be  per¬ 
formed  but  limited  to  only  those  cases  where  sub-expressions  can¬ 
not  be  pattern-matched  by  any  of  the  available  machine  instruc¬ 
tions  , 

The  code  generator  generator,  ACG,  will  utilize  this  high- 
level  code  derivation  scheme  in  a  manner  aimed  at  reducing  the 
problems  resulting  from  special-case  IL  operator  combinations. 
Previous  implementations  all  assumed  some  pre-defined  IL 
language.  The  IL  operators  constituted  the  same  low-level  primi¬ 
tives  used  to  describe  instruction  semantics.  In  contrast,  ACS 
will  allow  the  IL  language  to  be  user-defined,  A  set  of  low- 
level  primitives  will  be  provided.  The  semantics  of  the  IL 
operators,  like  the  semantics  of  the  machine  instructions,  will 
require  definition  in  terms  of  these  primitives.  Tn  essence,  ACCS 
permits  the  declaration  of  higher-level  IL  languages*  The  advan¬ 
tages  to  this  approach,  made  possible  by  the  hloh-level  code 
derivation  scheme  developed,  lie  in  the  ability  to  tailor  the  IL 
language  so  that  the  operator  semantics  are  similar  to  tnose  of 
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the  source  language  for  which  the  code  generator  is  required.  In 
this  respect,  the  basic  code  generation  units  (smallest  con¬ 
structs  requiring  template  representation)  are  the  primitive 
operator  combinations  denoting  the  source  language  operator 
semantics,  Equivalently,  those  primitive  operator  combinations 
occurring  most  frequently  in  programs.  In  previous  implementa¬ 
tions,  the  basic  code  generation  units  would  be  the  individual 
primitives  themselves.  Using  the  high-level  approach  proposed, 
compile-time  code  degradation  resulting  from  special-case  primi¬ 
tive  operator  combinations  can  be  substantially  reduced, 

Kinally,  ACC  must  provide  some  form  of  treatment  for 
special-cases  involving  operand  information.  This  aspect  of  code 
generator  generation  would  normally  present  difficulties  since 
the  high-level  approach  to  be  used  renders  no  direct  relation 
between  IL  operators  and  semantic  primitives.  Thus,  constructing 
templates  for  each  individual  machine  instruction  serves  little 
purpose.  The  code  derivation  scheme  can,  however,  be  used  to 
successfully  find  all  the  special-cases  associated  with  each  IL 
operator.  The  oblect  of  the  code  derivation  scheme  is  to  find 
the  best  code  sequence  for  a  given  semantic  expression.  Through 
the  use  of  parameterized  operands,  ACC  will  permit  the  code 
derivation  scheme  to  make  certain  assumptions  regarding  the 
values/locations  of  operands  in  its  search  to  find  the  best  code 
sequence.  Finding  all  special-cases  of  an  IL  operator  can  be 
accomplished  using  an  iterative  approach,  where  the  next  best 
code  sequence  is  derived  on  succeeding  interations.  The  template 
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returned  after  each  iteration  reflects  the  status  of  the  operands 


with  reaard  to  that  narticular  special-case ,  Parameter  restric¬ 
tions  are  entered  to  ensure  that  the  same  special-case  is  not 
re-detected  on  subsequent  iterations.  All  special-cases  will 
have  oeen  discovered  when  the  template  for  the  qeneral-case  (no 
operand  assumptions  reouiredl  is  returned. 

Given  the  qoals  of  this  woric  and  the  code  generator  genera¬ 
tion  approach  to  be  taken,  the  next  chapter  will  proceed  by 
presenting  a  more  elaborate  description  of  the  automatic  code 
generator  model  ACG,  The  sbeclfication  of  target  machines  and  IT. 
languages  will  be  given  first,  A  description  of  code  template 
production  and  template  use  at  compile-time  follows.  Where  used, 
the  term  "best  code  sequence”  will  mean  the  best  code  sequence 
obtainable  using  our  heuristics.  This,  of  course,  does  not 
necessarily  imply  the  optimal  sequence. 
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3.  ACG 


M  AUXaKAXXC  CQUE  GX^ltlJiAiaE 


3.1. 

The  autorridtic  cohe  generator  (ACG)  is  designed  for  the  pur¬ 
pose  of  producing  code  templates  for  user-defined  intermediate 
languages.  The  templates  are  intended  tor  use  by  a  table-driven 
code  generator. 

Input  to  ACG  consists  of  descriptions  of  the  target  machine 
and  intermediate  language  (II..),  The  language  description  defines 
the  semantics  of  the  IL  operators,  which  are  assumed  to  be  simi¬ 
lar  to  the  operators  of  the  source  language  for  which  the  code 
generator  Is  required.  The  machine  specification  provides  ACG 
with  all  the  details  required  to  derive  code  sequences  for  the 
target  machine, 

Hutput  from  ACG  consists  of  a  set  of  parameterized  tem¬ 
plates.  The  templates  define  the  actions  of  the  code  generator. 
Each  template  corresponds  to  some  IL  construct  and  specifies  the 
target  code  to  generate  at  compile-tlme  when  that  construct  is 
encountered.  Actual  operand  locations  are  substituted  In  place 
of  template  parameters  prior  to  use. 

Code  template  production  is  monitored  by  a  user-supplied 
program  which  interacts  with  ACG  to  control  the  type  and  number 
of  templates  created.  For  instance,  one  may  wish  to  derive  only 
a  minimal  code  generator  --  one  general-case  template  for  each  IL 
operator.  On  the  other  extreme,  the  user-program  may  direct  ACG 
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to  detect  and  nroduce  temniates  for  all  special-case  conditions 


associated  with  each  IL  operator. 

F’iqure  5  depicts  the  relationship  of  the  connnonents  of  ^CC, 

Alternatively,  ACG  can  be  used  to  derive  code  for  other 
machine-dependent  software.  Rather  than  specityinq  the  IL  opera¬ 
tor  semantics  in  the  lanQuaae  description,  the  description  can  be 
used  to  define  the  semantics  of  software  routines.  Producing  one 
general-case  template  for  each  semantic  definition  results  in  the 
derivation  of  the  desired  target  machine  code  sequences. 

Current  limitations  of  ACG  are  many  because  of  the  time  lim¬ 
its  imposed  upon  this  work.  In  particular,  the  following  res¬ 
trictions  are  applicable: 

-  operands  are  limited  to  single  data  types,  referenced 
using  one  of  three  addressing  modes  (memory,  register, 
cons tant l 

-  target  machine  instructions  can  produce  no  side  effects 
(Only  one  processor  state  location  value  can  be  modified 
by  any  individual  instruction.  For  example,  it  is  not 
currently  possible  to  reflect  the  setting  of  condition 
codes , ) 

-  template  production  is  limited  to  language  operations  with 
no  program  branching  effects 

These  limitations  are  determined  by  the  current  capabilities 
(level  of  deve I opemen t )  of  the  machine-independent  code  genera¬ 
tion  algorithms,  as  opposed  to  any  difficulties  that  may  be 
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encountered  with  eftecriveiv  dealing  with  such  njchine  architec¬ 
tural  features.  Although  these  restrictions  may  seen-  so'^ewhat 
severe,  the  model  is  more  than  adequate  tor  the  purooses  of  this 
work.  It  serves  its  Purpose  by  providing  a  realistic  working 
foundation  which  maintains  the  complexities  involved  with  search¬ 
ing  for  near-optimal  code  sequences  and  detecting  special-case 
conditions.  Generality  has  been  maintained  and  extensions  for 
converting  ACG  into  a  ful  1-scale  production  model  are  discussed 
in  chapter  5, 


3,2.  4C£  SamaoLlcs. 

Before  proceeding  with  the  target  machine  and  intermediate 
language  descriptions  for  ACG,  it  will  first  be  necessary  to 
define  how  instruction  and  operator  semantic  expressions  are  for¬ 
mulated. 

The  following  semantic  primitives  will  ne  used: 

<-  assignment 

,  contents  of  a  location 

addition 
-  negation 

♦  multipl icdtion 

/  division 

&  and  (bit-wise) 

I  or  (bit-wise) 
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complement  (bit-wise) 


=  equal 

<  less  than 

>  qreat er  than 

ft  bit  extraction  --  left  argument  is  the  source 

operand,  right  argument  soecifies  a  range 
of  bits 

:  range  seperator  --  first  ;  last  (bit  positions) 

,  concatenation  (of  two  separate  bit  ranges) 

All  of  the  above  operators  are  dyadic,  except  the  "contents  of* 
(,),  ''negation''  (-),  and  ''complement"  ("')  operations  which  are 
monadic . 

Operands  fall  into  one  of  three  classes: 

1 )  constants  and  addresses  -  denoted  by  either  a  string  of 

digits  (specific  value)  or  a  symbolic  name  (non¬ 
specific  value), 

2)  contents  of  a  machine  location  -  accessed  by  applying 

the  "contents  of"  (.)  operator  to  a  machine  address, 

3)  parameters  -  represent  possible  multi-addressing  mode 

operands  and  have  the  form  fil,  where  1  is  some  non- 
negative  integer, 

Examples: 
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4 


the  constant  4 


ABC  --  a  symbolic  address 
,A  •-  the  contents  of  location  A 
C2]  -•  second  Dr3rampter 

Three  basic  addressinq  modes  are  dlstlnqulshed: 

1)  immediate  (I)  -  reference  to  a  constant  or  machine 

address  • 

2)  register  direct  (B)  -  contents  of  a  register. 

3)  memory  direct  (m)  -  contents  of  a  memory  location. 

Symbolic  addresses  normally  refer  to  memory  locations,  Exceptions 
to  this  rule  are  the  symbolic  names  declared  to  be  registers  In 
the  target  machine  description,  Addressinq  mode  examples: 

4  <•>  mode  =  I 

,R0  <•>  mode  =  H  if  RO  previously  declared  to  be  a  register 
,A  <->  mode  =  if  A  not  declared  as  reaister 

Addressinq  mode  possibilities  for  parameters  are  specified  by  the 
user.  For  instance, 

mode  [4]  =  fVR 

defines  parameter  4  to  be  addressable  as  the  contents  of  either  a 
memory  location  or  a  register. 
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Semantic  expressions  take  the  form  of  assignment  statements. 


The  target  of  the  assignment  must  be  the  contents  of  some  machine 
location,  the  value  to  be  assigned  is  expressed  as  some  sequence 
of  primitive  operations  on  operands.  This  sequence  is  evaluated 
from  left  to  right  with  unary  operations  taking  precedence  over 
binary  operations.  Parentheses  can  be  used  to  alter  the  order  of 
evaluation.  Kxample: 


Expression;  . A<- [ 1 J  +  ( - , )  +  .C 
Tree  representation; 

/  \ 

.A  t 

/  \ 

+  .C 
/  \ 
cn  ♦ 

/  \ 

2 

I 

.B 


A  few  clarifications  may  be  in  order  concerning  the  ’’con¬ 
catenation”  (,)  and  ’’bit-extraction"  (H  operations.  The  con¬ 
catenation  operation  can  be  considered  the  inverse  of  bit- 
extraction,  in  that  the  former  appends  portions  of  words  that 
were  procured  by  the  latter.  For  instance,  to  swap  halves  of  a 
lb-bit  word  (left  blt=0,  right  bit=15)  for  some  location  denoted 
by  A,  the  statement 


.A<-( .Att(8: 15) ) , ( .A#(0; 7) ) 


expresses  the  desired  action.  It  should  be  noted  that  the  total 
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number  of  bits  concatenated  must  equal  the  size  of  the  destina¬ 
tion  operand,  hit-extraction  is  equally  apollcable  to  constants. 
It  will  be  assumed  that  the  binary  representation  of  a  constant 
is  expressed  uslnq  the  same  number  of  bits  contained  in  one  full 
machine  word.  Thus,  the  expression 

.A<-(0!?(0:7)  ) ,  ( ,A»(8:  lb) ) 

clears  the  left  half-word  of  location  A, 


3.3.  tiactiiae 

The  tarqet  machine  specification  is  relatively  straightfor¬ 
ward  as  only  the  components  essential  for  deriving  code  sequences 
need  be  described.  Two  basic  parts  compose  the  specification: 

1)  declaration  of  Intermediate  storage  locations 

2)  instruction  set  description 

Intermediate  storage  locations  are  declared  using  two  name 
lists.  The  first  list  contains  the  symbolic  names  of  usable 
registers,  while  the  second  list  provides  the  symbolic  address 
names  of  memory  locations  available  for  temporary  storage.  Exam¬ 
ple; 
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REGISTERS;  R0,R1,R2 
TEMPORARIES;  T0,Tl,T2 

The  second  portion  of  the  machine  speci f icat ion  involves  a 
description  of  the  tanet  machine  instruction  set.  Each  instruc¬ 
tion  is  defined  in  terms  of  the  following  Information; 

1)  symbolic  assembler  format 

2)  Instruction  semantics 

3)  parameter  addressing  modes 

4)  Instruction  execution  time 

A  sample  instruction  might  be  described  as  follows; 

iMSTPur  noN :  ado  [0],[1] 

SEMANTICS:  • ACC<- [01 f I  I J 

OPERAND  MODES;  [01 =R  [l]=M/R/I 

execution  TIME;  ,4R76 

Basically,  the  above  instruction  adds  two  operands  together,  the 
first  Of  which  must  he  located  in  a  register,  and  deposits  the 
sum  in  location  ACC.  All  parameters  defined  in  an  instruction 
are  local  to  that  particular  instruction  only.  Thus,  parameters 
can  be  re-used  (re-defined)  in  subsequent  instruction  descrip¬ 
tions,  Execution  times  are  represented  by  constant  values  and 
should  therefore  denote  the  minimum  or  base  time  required  for 
execution  regardless  of  the  actual  operand  addressing  modes  that 
might  be  used. 

The  reader  is  urged  to  refer  to  appendix  A,  where  three  com- 


Dlete  machine  specifications  are  presented. 


3,4.  Laaouaaa  aa&cillcaLiDa 


The  lann'idiqe  specif  icati  on  simply  consists  of  the  semantic 
diefinitions  of  the  IL  operators, 

tach  IL  operation  is  defined  by  a  set  of  simultaneous  equa¬ 
tions  using  semantic  expressions  to  denote  final  processor  state 
location  values,  nne  semantic  expression  is  required  for  each 
machine  location  assigned  a  value.  The  final  values  of  destina¬ 
tion  operands  are  expressed  in  terms  of  original  source  operand 
values.  Thus,  to  interchange  the  contents  of  two  locations  A,P, 
the  following  expressions  can  be  used: 

,a<-.b  .h<-,a 

Parameterized  operands  can  be  used  and,  as  In  the  machine 
specification,  addressab 1 1 i ty  modes  must  by  specified.  In  addi¬ 
tion,  machine  location  restrictions  can  be  imposed  upon  parame¬ 
ters  to  prevent  their  assignment  to  certain  locations  in  the 
event  that  special-case  detection  is  enabled. 

Locations  declared  as  temporaries  in  the  machine  description 
will  be  recognized  as  such  and  treated  accordingly  by  ACc;  during 
the  code  derivation  process.  The  final  value  of  a  temporary  is 
considered  to  be  undefined  following  execution  of  some  operation 
unless  the  user  explicitly  states  otherwise.  That  is,  by  assign¬ 
ing  the  temporary  a  specific  value,  np  the  other  hand,  non- 
intermediate  storage  locations  not  assigned  new  values  are 
guaranteed  to  retain  their  original  contents. 
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The  follo'A/inq  examole  describes  the  specification  of  an 
operation  that  adds  two  nnemorY  locations  and  places  the  result  in 
a  register  other  than  RO; 

C0]<-riJ+(?3 

[03;  MUnE=R  RESTRTCTIONS=,RO 
[13:  MODE=M 

f.23:  MODE=M 

To  facilitate  portability  of  language  specifications  between 
different  target  machines,  ACG  will  permit  user-defined  operators 
to  appear  in  semantic  expressions.  This  is  useful  in  that  the 
definition  of  some  language  operations  may  be  machine-dependent. 
User-defined  operators  are  denoted  by  symbolic  names  enclosed  by 
angle  brackets,  eg,  <nPUAME>,  A  pre-pass,  using  a  target  machine 
transformation  file  defining  the  conversion  of  user-defined 
operators  into  ACG  primitives,  is  performed  on  the  language 
soecif icat ion  prior  to  any  processing.  For  Instance,  a  "left- 
rotate”  operation  is  dependent  upon  the  target  machine  word  size: 

8-bit  word  --  [0i<-(  [03 «(1 :7) ) ,  ( [03 #(0:0)) 

16-blt  word  --  ro  1  <-(  [01  >*  ( 1  ;  IS) )  ,  (  [0  3  K  (0:0) ) 

Instead,  the  operator  <LRnTATE>,  denoting  "left-rotation",  could 
be  used  in  tlic  language  specification.  All  occurances  of  that 
operator  would  then  be  transformed  during  the  pre-pass.  Simi- 
larily,  act,  primitives  known  to  be  unmatchable  by  the  target 
machine  Instruction  set  can  be  re-defined  in  terms  of  other 


semantically  equivalent  primitive  operator  combinations. 


3.5.  Cade  Xfiaolat.ds. 

Code  templates  represent  the  output  from  ACG.  For  each 
semantic  definition  provided  as  input  to  the  machine-independent 
code  generator,  one  template  will  pe  produced  that  contains  not 
only  the  target  machine  code  to  generate  for  that  operation,  but 
also  other  information  pertinent  for  code  generation  purposes, 
Kach  template  is  composed  of  the  following: 

1)  Operand  map  -  a  one-to-one  mapping  of  operands  used  in 

the  semantic  definition  with  those  used  In  the  target 
machine  code  sequence  derived, 

2)  Temporary  locations  required  -  the  number  and  type  of 

intermediate  storage  locations  needed, 

3)  Locations  implicitly  used  -  specific  locations  (non 

instruction  parameters)  required  tor  computations  and 
Whose  contents  must  be  saved  if  currently  holding 
intermediate  results, 

4)  Target  machine  code  sequence  -  the  code  sequence  to 

generate  after  appropriate  actions  have  been  taken  to 
deal  with  the  above  three  steps. 

Template  examples  appear  in  appendix  C, 
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Use  of  code  templates  at  complie-time  by  a  tabie-drlven  code 
qenerator  can  be  described  as  follows: 

1.  First,  select  the  approorlate  temoiate  for  the  next  IL 
lanquage  contract  to  be  converted  into  code, 

2,  Using  the  template  operand  map,  determine  which  source 
operands  fall  to  conform  to  addressing  mode  requirements.  For 
each  such  operand,  allocate  temporary  storage  of  the  appropriate 
type  and  generate  code  to  perform  the  operand  transfer, 

3,  If  any  of  the  implicitly  used  locations  currently  hold  inter¬ 
mediate  results,  code  must  be  generated  to  transfer  the  contents 
of  those  locations  to  temporary  storage  elsewhere.  The  code  gen¬ 
erator  must  keep  track  of  where  these  intermediate  results  were 
transferred  since  they  will  be  required  for  future  computations, 

4.  Allocate  intermediate  storage  of  the  appropriate  type  for  tem¬ 
poraries  specified  In  the  template. 

Replace  all  template  parameters  by  actual  operand  locations  to 
be  used  and  generate  the  code  sequence  specified, 

6.  Ascertain  the  locations  of  destination  operands  using  the  tem¬ 
plate  operand  map. 
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7,  Free  all  temporary  storaae  that  had  been  allocated  except 
those  locations  containind  destination  results  (from  step  61  or 
those  containing  previous  Intermediate  results  (step  1 . 

The  above  procedure,  of  course,  requires  that  templates  exist  to 
perform  operand  transfers  (steps  2  and  3)  oi  the  form  [ll<-[il 
for  each  distinct  pair  of  operand  access  mode  combinations, 

3.6.  Cade  Gea&tdtion 

This  section  -*'111  discuss  methods  of  organizing  template 
production  for  entire  EL  languages.  Two  schemes  will  be  pro¬ 
posed. 

Template  production  is  governed  by  a  user-supplied  program 
(monitor)  that  interacts  with  ACG,  Basically,  the  monitor  sub¬ 
mits  one  semantic  definition  at  a  time  to  ACG  which  in  turn  finds 
the  best  code  sequence  and  produces  a  template  for  that  defini¬ 
tion,  Two  modes  of  operation  are  possible,  Tf  special-case 
detection  is  enabled,  ACG  will  derive  code  sequences  by  allowing 
assumptions  to  be  made  regarding  operand  values/locations.  These 
templates  will  normally  be  used  for  special-case  conditions.  If 
special-case  detection  is  disabled,  assumptions  win  be  confined 
to  operand  addressing  mode  restrictions  only,  in  this  sense, 
only  the  core  code  sequence  will  have  been  derived  (that  portion 
necessary  for  computation  of  results),  having  omitted  those  code 
portions  that  merely  perform  operand  targettinn  tasks  and  which 


can  be  separately  dealt  with  at  code  generation  time.  The  actual 
details  of  the  ACC. /monitor  Interface  will  not  be  discussed.  It 
is  only  important  to  understand  that  the  monitor  submits  a  single 
semantic  definition  (obtained  from  the  language  description 
file),  receives  a  template  in  return,  and  bases  its  next  action 
UDon  the  operand  assumptions  that  had  been  Imposed, 

The  first  scheme  for  code  generator  generation  to  be  con¬ 
sidered  involves  deriving  a  minimal  code  generator.  That  Is, 
producing  one  general-case  template  for  each  IL  operator.  This 
approach  might  be  used  in  cases  where  the  target  machine  has  lim¬ 
ited  core  memory  (eg.  a  microcomputer)  and  reducing  compiler  size 
is  of  utmost  importance.  Furthermore,  this  approach  is  applica¬ 
ble  when  the  language  description  contains  software  routine 
semantics,  instead  of  the  normal  IL  operator  semantics,  since 
treatment  of  special-case  conditions  Is  not  reguired. 

To  derive  a  minimal  code  generator,  the  task  of  the  monitor 
is  relatively  simple.  First,  special-case  detection  is  disabled 
and  the  semantic  definitions  of  the  IL  operators  are  supplied  to 
ACG  one  at  a  time  as  they  appear  in  the  language  description. 
For  each  definition  submitted,  one  general-case  template  will  be 
received  in  return.  Parameterized  operands  in  the  language 
description  should  have  no  addressing  mode  restrictions  imposed 
upon  them  (mode='i/R/n  since  general-case  code  seguences  are 
desired  and  because  ACG  will  automat ica 1 ly  determine  what  these 
restrictions  win  be.  Second,  operand  taroettina  templates  will 
be  reguired  for  use  in  coniunction  with  the  general-case 
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templates.  These  templates  can  be  created  by  havlna  the  monitor 
submit  expressions  of  the  form  Cil<-MJ  for  each  distinct  pair  of 
access  mode  combinations 

The  second  scheme  involves  deriving  f3  code  generator  that 
can  effectively  deal  with  soecial-case  conditions.  This  approach 
is  really  an  extension  of  the  first,  in  that  general-case  and 
operand  targetting  templates  are  still  regulred.  However#  the 
system  for  producing  templates  differs  as  the  monitor  must 
interact  with  ACG  on  an  iterative  basis  to  detect  special-case 
conditions.  Initially,  special-case  detection  is  enabled.  Then, 
for  each  IL  operator  definition,  the  basic  process  Involves  con¬ 
tinually  re-submitting  the  same  definition  to  ACG  in  an  effort  to 
find  all  special -cases  associated  with  that  It  operation.  Param¬ 
eter  operand  assumptions  C  locations/valuesl  made  on  previous 
iterations  are  restricted  from  occurring  on  subsequent  itera¬ 
tions,  thus  forcing  ACG  to  always  find  the  next  best  code 
sequence.  Assumptions  made  are  given  by  the  operand  map  portion 
of  a  template.  Operand  restrictions  are  thus  manually  set  before 
the  semantic  definition  is  re-submitted.  The  process  terminates 
when  a  template  is  returned  indicating  no  operand  assumptions  had 
been  made  other  than  addressing  mode  restrictions.  This  last 
template  represents  the  code  to  generate  for  the  gene ra  1 -case , 
Previous  templates  denote  special-cases.  The  special-case  condi¬ 
tion  that  a  template  is  applicable  for  is  determined  by  the 
unique  set  of  operand  assumptions  made  with  respect  to  that  tem¬ 
plate.  At  compile-time,  a  code  generator  would  first  check: 
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through  the  list  of  special-case  templates  associated  with 
operator  to  see  it  any  match  the  current  TL  construct.  If 
do#  the  aeneral-case  template  would  be  used  by  default. 


an  Til 
none 
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4,  UEEiiLAIlOIl  QE  JiiACiil]il£  CUOE  SEiaULLLCES 


4.1.  lotiiadiictlan 

In  chapter  3,  an  automatic  code  generator  model#  ACG,  was 
introduced.  Template  production  was  based  upon  the  existence  ot 
machine-independent  code  generation  algorithms.  This  chapter 
will  propose  algorithms  for  deriving  the  necessary  code 
sequences • 

First,  let  us  consider  the  machine-independent  code  genera¬ 
tion  Problem.  We  are  provided  with  two  givens: 

1)  a  machine  ^  -  having  Instructions  ■{ml,m2,,.,,mn> 

2)  a  goal  G  -  represented  as  a  set  of  simultaneous  equa¬ 

tions  denoting  final  processor  state  location  values 
(those  machine  locations  directly  involved  in  the 
operation)  for  which  code  is  to  be  generated  using 
the  machine  language  of  M 

The  objective  is  to  find  the  best  sequence  of  instructions 

mil  mi2  mi3  ...  mik 
semantically  equivalent  to  G. 

The  transformation  of  goal  G  into  a  sequence  of  machine 
instructions  can  be  performed  in  a  series  of  steps: 

G  =>  mil  G*  =>  mil  mi2  G"  =>  ...  =>  mil  mi2  ...  mix 

Fach  mij  reduces  the  current  goal  into  new  (and  hopefully 
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simpler)  sub-qoals.  However,  difticultles  are  Involved,  More 
than  one  instruction  may  he  applicable  at  any  qiven  step  of  the 
transformation  process.  Determining  which  instruction  to  select 
at  each  step  is  not  obvious,  as  the  decision  rests  upon  the  code 
that  will  be  derived  for  the  resultant  sub-goals, 

Findlna  the  best  code  sequence  for  a  given  goal  reduces  to  a 
classical  search  problem.  Investigating  all  possibilities 
(exhaustive  aoproach)  can  lead  to  a  comb i na tor i al ly  explosive 
situation.  Established  methodology  from  the  field  of  artificial 
intelligence,  namely  general  heuristic  search,  will  be  used  to 
effectively  deal  with  the  problem, 

4,2.  a&aLcU  tax  Eeax-Oallmal  Cade  aeaue-aoes 

4,2,1.  deaxcd  Cuaca 

Each  node  of  the  search  space  represents  a  state  of  the  tar¬ 
get  machine.  States  are  described  in  terms  of  binary  trees 
denoting  processor  state  location  values.  Only  locations  con¬ 
taining  non- initial  values  require  representation,  A  path 
between  any  two  nodes  exists  if  and  only  it  there  is  a  target 
machine  instruction  allowing  for  the  transition  from  one  machine 
state  to  another.  The  length  of  a  path  is  directly  proportional 
to  the  cost  incurred  had  the  corresponding  instruction  been  exe¬ 
cuted  on  the  target  machine.  The  cost  Js  measured  in  terms  of 
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Instruction  execution  time  and/or  space  requirements.  In  this 
sense,  it  is  possible  to  optimize  for  minimum  tirr'e,  minimum 
space,  or  some  weiqhted  combination  of  the  two  factors. 

The  initial  state  is  the  one  in  which  all  machine  locations 
contain  their  initial  values.  This  state  Is  represented  by  the 
empty  set  of  trees.  The  final  state  is  the  one  in  which  all  pro¬ 
cessor  state  location  values  match  the  qiven  set  of  goal  equa¬ 
tions  , 

The  problem  of  finding  the  best  code  sequence  for  some  given 
set  of  goal  equations  can  be  viewed  as  the  problem  of  finding  the 
shortest  weighted  path  between  the  two  nodes  representing  the 
initial  and  final  states. 


4,2,2,  aeax-cli  E£.ace.dui.& 

The  search  for  the  shortest  oath  emanates  from  the  final 
state  and  proceeds  along  paths  directed  towards  the  initial 
state.  In  effect,  code  is  derived  in  the  reverse  order  as  it 
would  be  executed: 

G  =>  G'  mike  =>  Q*  *  mil  mlkc  =>  ,,,  =>  mil  mi2  ,.,  mij  mlk: 

There  are  two  good  reasons  for  proceeding  in  this  direction. 
First,  since  the  initial  state  consists  of  the  empty  set  of 
trees,  the  processor  state  location  values  of  any  node  precisely 
define  the  remaining  sub-goals  requiring  transf ormat ion  into  code 
sequences.  The  obiective  then  Is  to  find  Instructions  which  can 
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pattern-match  the  current  processor  state  location  values,  A 
path  will  have  been  successtully  terminated  (initial  state 
reached)  when  all  processor  state  location  values  are  reduced  to 
their  initial  values  (the  empty  set  of  qoal  trees).  Conversely, 
some  method  would  be  requried  to  ascertain  the  exact  difference 
between  a  qiven  node  and  the  final  state.  Instruction  pattern- 
matchinq  would  then  have  to  be  attempted  upon  a  set  of  trees  or 
equations  denotinq  the  processor  state  location  value  differences 
between  the  current  and  final  states.  Secondly,  top-down  tree 
reduction,  as  opposed  to  bottom-up  reduction,  is  desirable. 
There  are  fewer  instruction  pattern-matching  possibilities  at  the 
root  of  a  goal  tree  than  there  are  at  the  leaves.  There  is  only 
one  root  node,  while  many  leaf  nodes  may  be  present.  Therefore, 
a  top-down  approach  has  the  effect  of  diminishing  the  number  of 
paths  emanating  from  search  space  nodes.  The  overall  result  will 
be  a  smaller  worKing  search  space. 

The  shortest  path  between  the  initial  and  final  states  is 
discovered  by  means  of  heuristic  search.  That  is,  successive 
evaluations  py  trial  and  error  are  used  to  arrive  at  a  final 
solution,  A  heuristic  function  exists  for  providing  termination 
estimates  (length  of  remaining  path)  from  any  search  space  node. 
The  purpose  of  the  function  is  to  direct  the  search  so  that  prob¬ 
able  solutions  (those  with  low  termination  estimates)  are 
attempted  first.  Hiah  estimate  nodes  may  ultimately  be  abandoned 
asnewsolutionsarediscnvered. 

Termination  estimates  are  based  upon  number  and  size  of  goal 
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trees  requirim  further  reduction.  For  each  noal  tree,  at  least 
one  instruction  will  have  to  be  qenerated  (assuming  instructions 
produce  no  side  effects).  An  estimate  of  the  additional  number 
of  Instructions  required  to  reduce  a  qoal  are  based  on  the  ooal 
tree's  size  (number  of  tree  nodes).  The  actual  termination  esti¬ 
mate  calculation  is  based  upon  the  total  number  of  expected 
instructions  required  for  all  the  goals  within  a  state. 

The  overall  effect  of  the  heuristics  is  to  limit  path 
traversal  attempts  to  only  those  that  are  liXeiv  to  lead  to  a 
Shortest  path  discovery.  Consequently,  a  combinator ial ly  large 
search  space  can  be  condensed  into  a  more  practical  and  workable 
size.  It  is  only  this  subset  of  the  combinatorially  large  search 
space  which  need  be  examined  in  order  to  find  near-optimal  code 
sequences , 

An  outline  describing  the  basic  organization  of  the  heuris¬ 
tic  search  is  provided  in  figure  6,  The  outline  has  been  simpli¬ 
fied  in  order  not  to  burden  the  reader  with  excessive  detail. 
One  point  is  worth  noting.  Only  states  representing  end  nodes  of 
uncompleted  paths  are  retained  over  the  course  of  the  search,  Tt 
would  be  infeasible  to  keep  a  permanent  record  of  all  nodes  pre¬ 
viously  visited.  As  a  consequence,  each  state  must  maintain  a 
record  of  the  exact  path  (code  sequence)  leading  to  its  deriva¬ 
tion,  The  term  active  search  space  will  henceforth  denote  those 
nodes  that  must  be  maintained  at  a  given  point  in  the  search. 

In  figure  6,  the  array  ACTIVE  is  used  to  store  the  current 
active  search  space.  Initially,  ACTIVE  contains  only  the  start 
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FIMDCnDKCSi ) {  /♦  find  best  code  sequence  to  reach  tarqet 

machine  state  denoted  by  SI  ♦/ 

ACTI VK<-’{ sn ;  maV:e  SI  the  start  state  ♦/ 

St<»0;  begin  with  no  terminal  state  ♦/ 

whileCACTIVE  not  emotyX  /*  until  search  is  completed  ♦/ 

Sj<-SEl,ECT( ACTIVE)  ?  select  from  ACTIVE  the  state  with 

the  lowest  termination  estimate  ♦/ 

REMnvE (SI , ACTIVE) ;  remove  Sj  from  ACTIVE  ♦/ 

NEw<-{>;  /*  initialize  list  for  malntalnlnq  new  states  ♦/ 

ADDCOERI VE(S1 ) ,NEW) ?  /♦  add  to  NEW  the  set  of  states 

derived  from  Sj  ♦/ 

ErNAL<-0;  /♦  initialize  terminal  state  list  */ 

EXTRACT(NK'W,EI  NAD ;  /»  extract  all  newly  derived  terminal 

states  from  NEW  and  store  in 
FINAL  ♦/ 

ADOCREMOVECFINAL, NEW) , ACTIVE) ;  /♦  add  all  newly  derived 

non-terminal  states  to 
ACTIVE  ♦/ 

foreachCSf  of  FINAL)!  /♦  determine  if  a  terminal  state 

exists  having  a 

if (PATHLENGTHCSf XPATHLENGTHCSt ) ) {  path  length  shorter 

than  that  of  the 

St<-St;  current  solution  ♦/ 

} 

foreachCSa  of  ACTIVE)!  /♦  remove  all  states  from  ACTIVE 

whose  termination 

If (ESTiMATE(Sa)>PATHLEMGTH(St ) ) (  estimates  exceed  that 

of  the  current 

RKMOVnCSa, ACT! VE) ;  solution  ♦/ 

1 

} 


returnCCDDECSt ) ) ;  /♦  end  of  search,  return  code  sequence 

>  derived  for  path  Sl->St  ♦/ 

Figure  6:  A  simplified  version  of  the  heuristic  search 
procedure  • 


state  Si,  The  overall  procedure  Is  iterative,  F.ach  step 
involves  selecting  from  ACTTVh:  the  state  Si  having  the  lowest 
termination  estimate,  deriving  new  states  from  Si,  and  storing 
any  non-terminal  states  derived  back  into  ACTIVE  for  later  pro¬ 
cessing,  The  variable  St  is  used  to  store  the  terminal  state 
having  the  shortest  path  length  of  all  solutions  discovered  up  to 
the  current  point  in  the  search.  Any  non-terminal  state  residing 
in  ACTIVE  will  be  discarded  if  its  total  path  length  estimate 
exceeds  that  of  the  current  solution  St,  The  search  concludes 
when  ACTIVE  contains  no  more  states  to  process,  indicating  all 
logical  alternatives  have  been  investigated.  It  is  important  to 
note  that  the  search  does  not  terminate  after  finding  an  initial 
solution  but  continues  in  an  effort  to  find  better  ones.  The 
first  solution  discovered  is  the  most  probable  one  and  is  nor¬ 
mally  the  overall  choice.  However,  for  completeness,  the  search 
continues  (time  permitting!  so  that  a  conclusive  result  (one  in 
Which  all  probable  solutions  are  examined)  will  be  obtained. 

The  heuristic  procedure  described  is  oriented  towards  a 
depth-first  search  rather  than  a  breadth-f ir s t  search  because  the 
next  state  selected  at  each  step  is  always  the  one  havina  the 
lowest  termination  estimate,  A  depth-first  search  is  desirable, 
as  the  active  search  soace  at  any  one  given  time  win  be  kept  to 
a  reasonable  size.  In  contrast,  a  breadth-first  search  would 
require  storage  tor  a  combinatorial ly  greater  number  of  nodes. 
In  addition,  a  depth-first  approach  results  in  the  prompt  deriva¬ 
tion  of  an  initial  code  sequence.  This  preliminary  solution 
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provides  a  realistic  ceiling  for  maximum  path  length  values.  As 
a  result,  nodes  having  termination  estimates  exceeding  this  limit 
can  be  discarded  in  the  early  stages  of  the  search. 


4,3,  U&rliLdliQQ  at 


4,3,1,  ^adcuti  audce  Que.c.aliaas 

Two  types  of  search  space  operations  are  performed  over  the 
course  of  the  search: 

1 )  state  transitions 

2)  state  transformations 

State  transitions  represent  oath  traversals  from  one  node  to 
another.  These  occur  whenever  a  target  machine  instruction  is 
used  to  totally  or  partially  reduce  some  goal  tree  of  a  state. 

State  transformations  denote  node  duplications.  That  is, 
the  new  nodes  created  represent  the  same  machine  state  but  with 
processor  state  location  values  (goal  trees)  transformed  for  the 
purpose  of  providing  access  to  additional  paths.  Three  types  of 


state  transformations  are  performed 


a)  destination  operan-i  tarqetting 

b)  common  sub-aoal  mergers 

c)  goal  re-def inlt Ions  (re-definition  of  a  goal  by  a 

different  but  semantically  equivalent  expression) 

State  transitions/transformations  win  be  discussed  In 
greater  detail  in  the  sections  directly  following. 

Associated  with  each  state  is  a  derivation  status  code. 
This  code  reflects  the  outcome  of  the  last  goal  reduction  attempt 
leading  to  the  state's  derivation.  Codes  are  set  as  follows: 

FAVORABIiE  --  normal  code  signifying  successful  reduction 

(total  or  partial) 

POSSIBLE  --  generation  of  simple  targetting  goals 

required  or  the  reduction  of  a  common 
sub-goal  prior  to  its  merger 

ADVERSE  --  generation  of  complex  targetting  goals 

required,  indicating  posslple  code 
redundancies 

Derivation  status  codes  provide  a  means  of  reducing  search  space 
size.  Basically,  they  indicate  which  state  transitions  or 
transformations  are  preferable.  Thus,  the  search  can  be  selec¬ 
tive  as  to  the  paths  that  will  and  will  not  be  traversed.  The 
precise  method  for  selecting  and  de-selecting  paths  will  be  given 
in  the  appropriate  section.  For  the  time  being,  it  is  only 
necessary  to  understand  the  fundamental  purpose  of  derivation 
status  codes  and  how  they  are  set. 
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4. 3 •2,  atate  g&ajiaaaatatlaa 

Each  machine  state  is  represented  in  terms  of  the  following 
Information; 

1)  Goals  -  processor  state  location  values#  organized  as 

one  or  more  sets  of  binary  trees 

2)  Code  sequence  -  target  machine  instruction  sequence 

(search  space  path)  leading  to  the  derivation  of  the 
state 

3)  Parameter  restrictions  -  permissable  addressing  modes 

and  location/value  restrictions  tor  each  parameter 
used 

4)  Restricted  destination  locations  -  locations  no  longer 

available  for  Intermediate  storaae  use 

5)  Derivation  status  code  -  status  of  the  last  state 

transit! on /transformation  resulting  in  the  derivation 
of  the  state 

Goals  are  arranged  tn  sets.  The  trees  in  any  given  set 
represent  simultaneous  equations  and  denote  processor  state  loca¬ 
tion  values  after  that  set  has  been  executed.  The  processor 
state  location  value  effects  between  states  is  transitive,  and  so 
a  sequential  ordering  is  required.  That  is,  locations  assigned 
values  in  preceeding  sets  retain  those  values  in  succeeding  sets 
(until  re-assigned  other  values).  Eor  instance,  the  state 
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defined  by  the  sinoie  set  of  qoals: 

<-  <- 

/  \  /  \ 

•A  +  .B  +  (set  #1) 

/  \  /  \ 

•c  .n  .c 

is  semantically  equivalent  to  the  state  defined  by  the  followina 
two  sets  of  aoals: 

<- 

/  \  (set  »2) 

•  A  ,H 

<- 

/  \ 

•  B  f  (set  # 1 ) 

/  \ 

.C  .[) 

In  both  cases,  locations  A  and  will  contain  ,C+*D  as  their 
final  values.  Sets  will  be  arranqed  such  that  the  correct  execu¬ 
tion  orderinq  is  from  the  bottom  set  to  the  topmost  set.  How¬ 
ever,  since  code  sequences  are  derived  in  the  order  opposite  to 
how  they  would  be  executed,  the  search  itself  commences  by 
attempting  to  reduce  the  topmost  set  first  and  proceeds  sequen¬ 
tially  downwards. 

The  reason  for  arranging  goal  trees  in  sets  is  to  facilitate 
the  setting  of  priorities  for  goal  reduction  attempts.  In  most 
cases,  states  are  represented  using  only  one  set  of  goal  trees. 
However,  during  the  course  of  the  search  it  may  be  necessary  to 
generate  sub -goals  for  operand  targettlng  purposes  or  for  common 
goal  tree  mergers.  In  such  cases,  the  sub-goals  must  be  reduced 
first.  Placing  these  sub-goals  in  a  separate  set  ensures  reduc- 
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tion  priority. 

□peran<i  information  Is  maintained  with  each  state  to  guaran¬ 
tee  the  proper  use  of  machine  locations.  First,  parameter  loca¬ 
tion  restrictions  are  required  to  ensure  that  locations  are  not 
inadvertently  shared.  That  is,  preventing  the  simultaneous 
storage  of  two  or  more  different  values  in  the  same  machine  loca¬ 
tion,  Second,  since  tne  search  is  performed  in  reverse  sequen¬ 
tial  order,  locations  whose  original  values  are  used  in  goal 
reductions  must  be  forbidden  to  be  used  as  the  target  operand  of 
any  remaining  sub-goals.  This,  in  effect,  prevents  derivation  of 
code  in  which  source  operand  values  are  erroneously  •’clobbered** 
before  their  actual  use. 


4.3.3,  Qq.s.1  EaducJLlans. 

Goal  reductions  represent  machine  state  transitions,  A  goal 
tree  is  reduced  by  pat  tern-matching  an  instruction  tree  with  the 
goal  tree.  New  sub-goals  are  created  at  the  points  where 
instruction  operands  and  corresponding  goal  tree  nodes  mismatch. 
Two  prerequisites  for  goal  reduction  must  be  satisfied, 
fine,  operator  nodes  of  the  instruction  tree  must  directly  match 
(be  identical  to)  the  corresponding  goal  tree  nodes.  Two,  the 
destination  or>erar\ds  of  both  trees  must  be  compatible. 

Compatibility  between  two  operands  will  be  defined  as  fol¬ 
lows.  Klther  both  operands  refer  to  the  same  1 ocat ion/va lue  or 
at  least  one  must  he  a  parameter  and  capable  of  being  replaced  by 


the  other.  Replacement  is  dependent  upon  the  addressability 
modes  and  current  locat ion/val ue  restrictions  of  the  parameters 
involved.  In  cases  wnere  one  parameter  replaces  another  parame¬ 
ter,  the  substitution  parameter  must  take  on  the  addressing  mode 
and  locat ion/va lue  restrictions  of  both  parameters.  In  other 
words,  if  parameter  CXI  is  to  replace  parameter  [YJ »  the  new 
addressapility  modes  for  fxj  will  be  those  that  were  common  to 
Doth  (the  intersection)  and  new  locat ion/val ue  restrictions  will 
be  the  union  of  the  previous  restrictions,  Kxampie: 

(25):  N!GDK  =  M/R  RKSTR1CTT0NS=,R0 ,  .PI 

C27J:  r^UDt;=R/l  RKSTP  rCTinNS=  ,R1  ,  ,R2 

Replacina  127]  by  [253  has  the  tollowina  effect: 

(253:  MnDK=R  RKSTRlCTinNS=,RO , ,P3 , . R2 

The  purpose  of  determining  operand  compatibility  is  to 
ascertain  which  Instruction  operands  are  replaceable  by  loal  tree 
operands.  If  the  destination  operands  are  incompatible,  goal 
reduction  cannot  be  performed  because  trees  are  reduced  top-down 
and  not  bottom-up.  Hence,  if  destination  targetting  is  required, 
sub-goals  must  be  set  up  to  reflect  this  need  and  the  appropriate 
targetting  code  generated  before  the  instruction  is  applied,  nn 
the  other  hand,  source  operand  compatibility  is  not  a  prere¬ 
quisite,  This  type  of  targetting  can  be  dealt  with  after  the 
instruction  is  applied.  Reducing  a  goal  tree  in  which  source 
operand  incompatibilities  exist  simply  results  in  the  generation 
of  the  required  source  operand  targetting  sub-goals,  vSystem- 
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generate^i  parameters,  rlenotlm  temporary  storage  requirements, 


are  used  in  place  of  local  instruction  parameters  when  incompati¬ 
bilities  occur. 

A  reduction  example  will  now  be  provided.  Suppose  we  are 


given  the  following 

instruction  and 

goal  trees 

t 

• 

instruction : 

<- 

/  \ 

101  : 

MODErM/R 

CO)  t 

/  \ 

[11 : 

modf:=m/r/i 

[01  + 

/  \ 

[21 : 

modf:=r 

ril  121 


COAL:  <- 

/  \ 

.  A 

/  \ 

/  \  /  \ 
.B  ,c  .0  .f: 


Assuming  location  A  can  be  used  as  a  destination  location,  the 
prerequisites  for  goal  reduction  are  satisfied  ([0],.A  are  compa¬ 
tible  and  corresponding  operator  nodes  match).  Operand  ,A 


replaces 

all 

occurrences 

Of  parameter 

[0]  and 

pattern -matching 

the  right 

sub- 

trees  results 

in  the  following  temporary  sub-goals: 

\ 

<- 

<  - 

<- 

[11: 

MnDE=w./R/l 

/ 

\ 

/ 

\ 

/  \ 

.A 

♦ 

f  1  1 

.D 

[21  .E 

[21  : 

MnDE=R 

/  \ 

.B  .C 


Source  operands  tl],.()  are  compatible.  Replacing  til  by  .D 
results  In  the  transformed  sub-goal  .rx-.D  which  is  redundant  and 
removable.  On  the  other  hand,  [21, .t  are  incompatible  ([21  is 
only  addressable  as  a  register)  and  so  the  sub-goal  r2)<-.F"  must 
remain.  This  goal  denotes  a  source  operand  targettino  need.  The 


final  result  ot  the  reduction  after  reolacinq  local  instruction 


parameter  [7]  with  a  systen-aenerated  parameter,  say  [543,  is 
therefore  the  follow  Inq: 

<-  <- 

/  \  /  \  [541:  MODK=P 

.A  ♦  [  5  4  3  .E' 

/  \ 

.B  .C 

Parameter  restrictions  arise  durino  qoal  reduction  opera¬ 
tions,  The  settinq  of  restrictions  involves  all  existinq  oarame- 
ters  in  the  state  representation,  not  just  those  of  the  current 
instruction  and  qoal  trees.  Basically,  restrictions  are  based 
upon  current  processor  state  location  values.  Any  location  con- 
taininq  a  value  differim  from  that  of  a  parameter  must  neces¬ 
sarily  he  considered  a  restricted  location  for  that  parameter, 
Otherwise,  an  assiqnment  of  the  location  to  the  parameter  Cin 
some  future  step)  would  result  in  the  location  loqically  contaln- 
inq  two  different  values  simultaneously.  Restrictions  are 
entered  prior  to  reducinq  a  qoal  tree  and  whenever  redundant 
sub-qoals  are  to  be  removed.  Suppose  in  the  previous  example 
another  qoal  had  existed  in  the  state: 

<- 

/  \ 

[523  +  [523:  MGDE=M/P 

/  \ 

.B  ,0 

The  followinq  restrictions  would  have  had  to  been  imposed; 

[  523  :  M()Dt;  =  M/R  RKSTHICTIOMSs,  A  ,  ,n,  [543 

[  543  :  ht)DK  =  R  RFSTRICTIONSr  [523 

Note  that  parameter  (543  did  not  have  to  be  restricted  from  .A  or 
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,D  Since  addressability  mode  contlicts  render  such  replacements 
impossible.  New  restrictions  are  searched  for  prior  to  testlnq 
tor  source  operand  compatibilities,  Revertinq  to  the  previous 
example,  the  sub-goal  tn<-,D  was  removable  due  to  the  compati¬ 
bility  between  the  two  operands,  however,  had  another  goal 
existed,  say: 

<- 

/  \ 

.D  + 

/  \ 

.B  ,C 

then  ,L)  would  have  to  be  a  restriction  of  111,  Otherwise,  the 
replacement  of  til  by  ,0  results  in  location  D  simultaneously 
containing  two  different  values: 

<-  <- 

/  \  /  \ 

, D  , D  ,0  + 

/  \ 

,B  ,C 

Determining  restrictions  prior  to  testing  for  operand  compatibil¬ 
ities  ensures  conflicts  like  the  above  will  not  occur ,  The  sub¬ 
goal  ri  !<-,!)  (where  til  would  be  replaced  by  a  system-generated 
parameter)  would  have  to  remain  as  a  source  operand  targetting 
suh-goal.  Tne  targetting  need  arises  from  an  attempt  to  use  the 
initial  value  of  ,D  before  reducing  the  goal  tree  that  reassigns 
,0  another  value.  Had  the  targetting  need  been  waived,  we  would 
have  in  fact  generated  code  using  the  incorrect  value  for  ,D, 

The  derivation  status  code  setting  for  a  reduction  operation 
is  normally  "FA\/0R  AObE" ,  However,  it  a  tree  is  a  sub-goal  of 
another  and  is  reduced  prior  to  any  merger  attempts,  a  status 
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code  of 


"POSSIBLE" 


will  be  set. 


This  code  indicates  that 


althouqh  a  successful  reduction  was  performed,  possible  optimiza¬ 
tions  may  have  been  byoassed.  An  "ADVERSE"  code  will  be  returned 
if  any  source  operand  palrinqs  are  deemed  incompatible  because 
one  of  the  operands  exists  as  the  destination  operand  of  some 
other  goal.  In  such  cases,  the  resultant  tarqettino  goal  could 
possibly  have  been  avoided  had  the  other  goal  tree  been  reduced 
first.  The  derivation  status  code  "ADVEPSE"  denotes  this  prob¬ 
able  tarqettinq  redundancy. 

Finally,  it  should  be  noted  how  the  reduction  process  is 
effected  when  special -case  detection  is  enabled.  When  disabled, 
a  distinction  is  made  oetween  user -defined  parameters  and 
system-qenerat ed  parameters.  User-defined  parameters  are  those 
parameterized  operands  appearing  in  the  initial  semantic  defini¬ 
tion  obtained  from  the  language  description  file.  System¬ 
generated  parameters,  in  contrast,  are  those  created  during  the 
course  of  the  code  derivation  process  and  denote  temporary 
storage  requirements.  The  distinction  between  the  two  is  taken 
into  account  when  checking  for  operand  compatibilities.  System¬ 
generated  parameters  are  permitted  to  be  replaced  by  specific 
machine  locations  or  values.  Such  actions,  however,  are  prohi¬ 
bited  for  user-defined  parameters.  Thus,  if  a  machine  instruc¬ 
tion  operand  denotes  a  Particular  location/ value  and  the 
corresponding  goal  tree  node  is  a  user-defined  parameter,  the  two 
will  be  deemed  Incompatible  and  tarqettinq  sub-goals  will  be 
required,  when  special-case  detection  is  enabled,  the 
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distinction  between  user-defined  and  sys tem-qenerated  parameters 
is  dropped.  User-defined  parameters  are  treated  as  though  they 
were  system-generated  parameters.  This  permits  binding  of  param¬ 
eters  used  in  the  language  specification  to  locat ions /values  If 
such  actions  result  in  better  code  sequences  being  derived.  The 
following  example  Illustrates  the  difference  obtained  when  code 
is  generated  for  the  aoal 

<- 

/  \  [01:  M0DE=M/R 

[0]  +  m;  M0DE=M/R/I 

/  \  [23:  MC)DK=M/R/I 

til  [21 

using  the  Instruction  set  of  machine  A,  Two  pattern-matching 
possibilities  exist: 

ADD  [01  . ACC<-, ACC+ [01  tOl:  M0DE=M/I 

INC  ,ACC<-,ACC-H 

First,  when  special-case  detection  is  disabled,  the  code  derived 
and  accompanying  operand  map  will  be: 

rnOE  nPERAND  MAP 

m  mm  m  m  «•  ••  W  «p  ai  «p  «• 

LO  til  [0]  =>  [03  MQDE=M 

ADD  [21  [13  =>  [13  MODE=M/I 

ST  [0]  [23  =>  [23  MGDF=M/I 

Since  the  user-defined  parameters  < [03  ,  [  1 1  ,  [21 >  cannot  be 

replaced  by  specific  locations/values,  targetting  goals  are 

required  and  reduced  using  LD  and  ST  instructions.  The 

corresponding  goal  restructuring  required  to  yield  this  general- 

case  code  sequence  is  representable  using  three  sets: 
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<- 

/  \ 

COJ  ,ACC 

(ST  [01  ) 

<- 

/  \ 

.ACC  f 

/  \ 

.ACC  [?J 

f  ADD  [2]  ) 

<- 

/  \ 

.ACC  [IJ 

(LI)  [11  ) 

It  should  be  noted 

that  the  INC  instruction  is  not  applicable. 

Using  it  results 

in  the  generation  of  an  illegal  sub-goal  (1<- 

C2] )  which  has  a  constant  as  the  taroet  operand.  When  special- 
case  detection  is  enabled,  the  user-defined  parameters  can  be 
directly  replaced  by  the  corresponding  Instruction  tree  operands. 
Both  instructions,  Aon  and  INC,  are  applicable  In  this  case. 


However,  since  INC 

has  a  faster  execution  speed,  it  will  be 

selected  over  Ann, 

The  result  is  the  following: 

CODE 

«*  «  w  • 

OPERAND  MAP 

INC 

[0]  =>  ,ACC 
[11  =>  ,ACC 
[23  =>  1 

4.3.4, 

Destination  operand  target  ting  is  a  prerequisite  for  goal 
reduction  if  tne  corresponding  instruction  and  goal  tree  operands 
are  incompatible,  F'our  types  of  targetting  are  performed.  Each 
is  based  upon  the  type  of  location  required  by  the  instruction 


and  the  machine 

state  conditions  governing  usage  of  that 

1 

O' 

o 

1 

location.  New  sub-goals  generated  are  placed  in  separate  sets  to 
indicate  their  reduction  priority. 

1 

Conditions; 

Non-specific  location  ( parameter )  reauired  that  conforms  to 
the  addressability  modes  specified  by  the  instruction. 

Actions; 

1)  generate  a  parameter,  say  (X],  conforming  to  the  addressabil¬ 
ity  mode  reguiremenfs 

2)  replace  the  destination  operand  i)  by  IXJ 

n  generate  a  sub-goal  to  move  the  contents  of  fX]  to  D 


iLXdmp  le 


qoal;  <- 

/  \ 

.  ^  + 

/  \ 

.p  .c 

destination  muirenient:  any  renister 
tar netting  action: 

<-  [ 4P 1  :  Mnn^rR 

/  \ 

.A  r4Pj 

<- 

/  \ 

f  48]  + 

/  \ 

.P  .C 

Derivation  status  code: 

"POSSIBLE",  to  denote  simple  targettlna 


2 

Conditions : 

Specific  location  required  that  is  available  for  use  (no 
destination  restrictions  exist  nor  is  it  used  as  the  destination 
operand  of  another  goal). 

Act i ons ; 

1)  replace  the  destination  operand  D  by  the  required  location  L 

2)  generate  a  sun-goal  to  move  the  contents  of  I.  to  n 
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Kxamp 1 p 


q  o  a  1  :  <  - 

/  \ 

.A  + 

/  \ 

.B  .C 

destination  requirement:  ,ACC 
tarqettinq  action: 

<- 

/  \ 

.A  .ACC 

<- 

/  \ 

.ACC  a 
/  \ 

.B  .C 


Oerivatlon  status  code: 

”  pnss  T  Br.E  ”  ,  to  denote  simple  targettino 


X;^a£  i 


Con(iitions: 

Specitic  location  required  hut  one  which  is  currently  in  use 
as  the  destination  target  of  some  otner  cjoal  , 


Actions: 

1)  generate  a  parameter,  say  fXl,  having  universal  mode  (M/R/T) 

2)  find  the  goal  tree  using  the  required  location  L  as  a  destina¬ 
tion  operand  and  replace  L  by  [X] 

3)  replace  the  destination  operand  D  of  the  goal  requiring  tar¬ 


getting  by  Li 


4)  venerate  a  sub-qoal  to  move  the  result  computed  in  I.  to  t*^e 


intended  tanet  n 

5)  Generate  another  sub-qoa]  to  move  the  contents  ot  TXJ  to  L 


f*:  X  a  m  D 1  e  : 

doals:  <- 

/  \ 

.A  f 
/  \ 

.B  .r 

destination  requirement: 
tarqettinq  action: 

<- 

/  \ 

.RO  (S41 

<- 

/  \ 

,  A  ,R0 

<  - 

/  \ 

,  RO  + 

/  \ 


<- 

/  \ 

,R0  + 

/  \ 

.D  .E 

RO  (for  the  first  qoal) 


[541:  wnnK=M/R/i 


<- 

/  \ 

fh4]  + 

/  \ 

.  D  .  f: 


.B  .C 

Derivation  status  code: 

"ADVERSE",  denotinq  qeneration  of  sub-noals  which  could  have 
been  avoided  had  the  tree  usinq  the  required  destination  location 


been  reduced  first 


Conditions: 

Specific  location  required  but  one  which  has  been  prohibited 
from  further  use  as  a  destination  operand. 

Actions : 

1)  qeneratP  a  parrimeter,  say  fXl  ,  of  universal  mode 

2)  replace  the  destination  operand  D  of  the  qoal  tree  by  the 
required  location  \, 

3)  add  to  the  current  set  of  doals  a  new  qoal  in  which  the  con¬ 
tents  of  L  are  saved  in  [XI 


4) 

qener at e  a 

sub-qoal 

to 

move  the  result  computed 

in 

L  to  D 

S) 

qenerate  a 

sub-qoa l 

to 

restore  the  contents  of 

L 

uslna  the 

value  field  in  [XI 


Example 


aoal:  <- 

/  \ 

.A  4 

/  \ 

.n  ,r 

destination  r equ i remen f :  ,K 

tdrqettim  action: 

<-  [773:  MnUE  =  ^'/P/T 

/  \ 

, n  r  77  1 

<- 

/  \ 

.A  ,R 

<-  <- 

/  \  /  \ 

.P  +  [771  .R 

/  \ 

.B  .r 


Derivation  status  code: 

"  AD  VEPvSK" ,  denotim  tanettinq  difficulties  arise  due  to  the 
instruction's  destination  location  demands 


4.3.5.  Camman  auu-uaal  ii.e.Lae.L& 

C,oal  meners  are  attempted  prior  to  performinq  qoal  reduc¬ 
tions  upon  a  state.  Any  new  states  derived  are  added  to  the  list 
of  active  states  (tnose  awaitinn  further  reductions).  Tlius,  new 
states  created  tiy  merainq  do  not  replace  the  state  from  which 
they  were  deriveci.  Instead,  they  serve  as  qateways  to  alternate 
search  scace  paths  that  may  allow  for  the  derivation  of  addi¬ 
tional  (potentially  better)  code  sequences, 

-  f)6  - 


Thp  basic  procedure  involves  findim  dll  pairs  of  qoals 


whose  riqht  sub-trees  are  identical,  I'or  each  such  pair  of  qoals 
discovered,  two  new  states  are  produced  by  'rerqinq  the  qoals  as 


follows: 

noal  pairinq: 

<-  <- 

/  \  .  ,  .  /  \  ... 

X  <vST>  Y  <ST> 

where  X,Y  are  any  operands  and  <ST> 
is  the  common  sub-qoal 

merger  1 : 

<  - 

/  \ 

X  Y 

<- 

/  \  ... 

Y  <ST> 

m  p  r  q  e  r  2 : 

<- 

/  \ 

Y  X 

<- 

/  \  ... 

X  <ST> 

Two  points  are 

worth  notlnq.  First,  the  merqer  procedure  is 

not  concerned  with  embedded  common  sub-aoals.  That  is,  suppose 
the  folio winq  pair  of  qoals  exist  in  some  state: 


A 

t 

A 

1 

.A  +  ,1)  ♦ 

/  \  /  \ 


.F  + 

/  \ 

.r 

"'10  meraers  would  be  performed.  Any  such  actions  will  be  delayed 
until  a  state  is  Produced  in  which  the  rinht  sub-tree  of  the 


second  qodl  has  neen  reduced  from  .K+(,Hf.C)  to  .Bf.C,  ftnly  then 


would  the  two  ]oals  be  mer ted.  Second,  since  states  derived  due 
to  merqina  are  placed  nack  on  ttie  active  slate  list,  it  should  be 
apparent  tt'at  if  multiple  occurrences  of  the  same  sub-qoal  exist, 
they  will  ^^11  eventually  he  merged.  In  fact,  all  possible  meroer 
combinations  (in eluding  non-meraers)  will  result. 

Two  state  derivations  are  generally  required  for  each  pair 
of  common  suP-goals,  The  destination  operands  may  he  of  dif¬ 
ferent  addressability  modes  and  it  may  be  more  beneficial  to  cal¬ 
culate  the  result  in  one  than  the  other.  This,  of  course,  is 
dependent  upon  the  instructions  that  will  be  aenerated  tor  the 
common  sub-goal.  f;ven  if  both  destination  operands  are  of  the 
same  mode,  better  code  derivations  nay  still  exist  exist  for  the 
one  merger  that  do  not  for  the  other.  The  character  I st ics  of  the 
target  machine  instruction  set  determine  this  factor.  An  example 
will  be  Provided  using  the  instruction  set  of  machine  C  to  derive 
code  for  the  goals; 


<- 

/  \ 


<- 

/  \ 


A 


-f 


/  \ 


/  \ 

,A  ,C 


.A  ,C 


The  first  merger  results  In  the  configuration 


6B 


<- 

/  \ 

.A  .M 

<- 

/  \ 

,  H  + 

/  \ 

.A  .C 

N 

with  bpst  possible  code  sequence: 

mo V  A  ,  b 
ddd  C,B 
m  o  V  H  ,  A 

However,  for  the  second  merqer: 

<- 

/  \ 

.  e  .A 

<- 

/  \ 

.  A  ♦ 

/  \ 

.A  .C 

ri  better  code  seciuence  Crin  be  derived: 

d  d  i  C  ,  A 
m  O  V  A  ,  B 

Cdses  whore  sinaip  meroers  can  oe  performed  exist  whenever 
the  destination  operands  of  the  common  sub-qoals  are  compatible. 
This  Implies  that  at  least  one  of  the  operands  is  a  parameter. 
In  such  instances,  the  only  action  is  to  replace  that  parameter 
by  the  other  destination  operand  and  remoye  either  one  of  the 
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doa  I  s 


i-’  X  a  m  p  1  e  : 


<- 

/  \ 

14R1  f 


<- 

/  \ 

A  + 


/  \ 
n  ,c 


AssuTiinq  (4«J  and  ,A  are  comoatlble,  the  mprqer  slTOly  results  in 
the  folio winq: 

<- 

/  \ 

.A  ♦ 

/  \ 

•  B  .f 

after  havinq  marked  the  replacement  of  parameter  [481  hy  .A, 

The  derivation  status  code  returned  from  qoal  merqer  opera¬ 
tions  is  "FAVDRABhK" ,  However,  the  code  is  irrelevant  as  merqers 
are  performed  prior  to  any  qoal  reduction  attempts. 

4.3.6.  Goal 

A  qoal  tree  js  re-defined  if  and  only  if  no  feasible 
instructions  can  he  found  to  reduce  it.  ACC  maintains  a  list  of 
tree  transformation  rules.  Based  on  the  primary  operator  of  the 
qoal  tree  (root  node  of  the  right  sub-tree),  one  of  these  rules 
is  selected.  I’he  rule,  if  one  exists  for  the  operator,  will 
specify  a  semantically  equivalent  transformation  for  the  sub-tree 
by  re-defininq  tl^e  semantics  of  the  primary  operator  in  terms  of 
other  primitive  operator  combinations. 

The  goal  transformation  rules  currently  in  use  are: 
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-X 

A 

II 

It 

V 

~X-f  1 

A 

II 

II 

V 

“'(’“X  n  y ) 

X  1  Y 

A 

II 

II 

V 

^  y. 

A 

II 

II 

V 

-(X+1 ) 

■ 

>- 

II 

X 

A 

II 

II 

V 

•'(  (X<Y)  1  (X>Y)  ) 

X<Y 

A 

II 

II 

V 

''(  (X  =  Y)  1  (X>Y)  ) 

X>Y 

A 

II 

II 

V 

(X  =  Y)  1  (X<Y)  ) 

As  an 

example, 

supDose  no  Instructions  could 

reduce  the 

follow! no 

aoa  1 

tree : 

<- 

/  \ 

.A  I 

/  \ 

+  .0 

/  \ 

.H  .C 


found 


to 


The  primary  ooerator  is  'I'  and  so  the  qoal  would  be  re-defined 
ds : 

<  - 

/  \ 

.A 

I 

/  \ 


/  \ 

.B  .r 

The  transformation  rules  are  intended  for  use  only  as  a 
means  of  recovery  from  situations  Involvinq  irreducible  goal 
trees.  Goal  t rans f ormat 1 ons  are  not  used  in  the  search  for 
near-ootimal  code  sequences,  A  limit  Is  established  so  that 
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t  rans  f  orrrat  Ions  are  attempted  at  most  once  on  anv  Given  (?oal 
tree.  The  reader  may  have  observed  that  manV  of  the  transforma- 
tion  rules#  if  annlled  ^'Ore  tnan  once,  tend  to  be  cyclic.  Obvi¬ 
ously,  better  scnemes  exist  for  recovering  from  irreducible  goal 
situations.  In  oarticular.  Cat t el 1 1 1 d7 8 1  has  a  scheme  which 
employs  means-ends  analysis  to  transform  a  tree  Into  the  seman¬ 
tics  of  the  available  machine  instructions  (if  at  all  possible 
within  reason).  However,  finding  equivalent  goal  tree  transfor¬ 
mations  is  not  the  tonic  of  this  worK.  Cattell's  method  could 
easily  be  intearateci  with  ACG  and  used  to  find  alternate 
representations  for  irreducible  goal  trees.  F'or  this  work, 
though,  the  simnie  transformation  method  proposed  will  be  used 
only  as  a  last  ditch  effort  for  recovering  from  hopeless  situa¬ 
tions,  Irreducible  operations  can  additionally  be  circumvented 
by  re-defining  the  semantics  of  such  operations  during  the 
language  description  pre-pass. 

The  derivation  status  code  returned  from  transformation 
operations  is  "FA VORABLF!" ,  ■'Jormally,  a  '’FA VOPAHLF"  code  denotes 
a  successful  reduction  operation.  However,  in  this  case  it  is 
necessary  to  "trick"  ACG  into  believing  a  successful  reduction 
had  been  performed.  The  psuedo  code  returned  ensures  reduction 
priority  for  the  transformed  goal  when  search  space  size  reduc¬ 
tion  technigues  are  in  effect.  This  is  basically  a  matter  of 
efficiency.  If  the  goal  cannot  he  reduced  on  the  second  attempt, 
then  there  is  no  point  in  continuing  the  search. 
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4.3,7.  n&LL^tiLLaa  ^iauLitliai 


Havinci  presented  the  search  space  operatiohs,  A'e  may  now 
proceed  with  the  aldorlthir  which  utilizes  these  operations  to 
derive  new  states.  The  riiqorjthm  is  diver  in  fidure  7,  Tt 
derives  new  states  from  a  specified  aoal  tree  of  a  given  state. 
This  algorithm  could  be  applied  to  each  goal  tree  of  the  chosen 
state.  However,  to  reduce  search  space  size,  this  is  undesir¬ 
able,  Determining  which  goal  tree  to  select  for  reduction 
attempts  is  discussed  in  the  next  section. 

The  algorithm  for  deriving  new  states  is  rather  straightfor¬ 
ward,  First,  ail  feasible  Instructions  for  reducing  the  selected 
goal  tree  are  found.  Feasible  instructions  are  those  whose 
operator  nodes  pat  tern-match  the  goal  tree,  taking  commutation 
rules  into  account.  If  no  such  instructions  exist,  a  new  state 
is  created  by  re-defining  the  goal  tree  in  terms  of  a  different 
primary  operator.  Otherwise,  for  each  feasible  instruction,  two 
possibilities  exist.  One,  the  instruction  cannot  be  applied 
because  the  destination  operands  of  the  Instruction  and  goal 
trees  are  incompat ib 1 e ,  In  this  case,  destination  operand  tar- 
getting  will  be  oerformed.  Two,  the  instruction  can  be  applied. 
All  commutative  forms  of  the  Instruction  tree  are  found  which  are 
capable  of  pattern-matching  the  c^oal  tree,  Fach  such  tree  Is 


then  used  to  reduce  the  goal  to  create  new  states 


NfcJWSTATES ( S f G )  <  /♦  'ierive  ne>’  states  from  state  S  uslnq  qoal 

tree  G  ♦ / 


NEW<-{>;  /♦  Initialize  list  tor  storing  new  states  ♦/ 

I<-lMSTHllcriGJS(G');  /♦  ciet  List  ot  feasible  instructions  for 

reriuclnq  goal  G  ♦/ 

it(T  is  empty)!  /♦  tf  no  feasible  Instructions  exist,  add  the 

state  derived  by  transforming 
ADDCTRANSFGHM  (  S,G)  ,  rJEW)  ;  goal  tree  G  of  state  S  ♦/ 

) 

else!  /t  otherwise  ♦/ 

foreachCIK  of  1)!  /♦  tor  each  feasible  instruction  Ik  t/ 

if  (CG^PAT  [  FiLEif  Tk  ,G)  =  0)  !  /♦  if  destination  operand 

targettino  required,  add  to 
ADU(TARGfc;T(s,(;,  Ik)  ,Ne:w)  ;  ne:w  the  state  created  by 

setting  up  sub- goals  to 
reflect  the  targettinq 
}  need  */ 

else!  /♦  otherwise  instruction  Ik  can  be  applied  to 
goal  tree  G  */ 

COMLIST<-cnMMiiTE(  Ik  ,G) ;  /*  find  all  commutations  of 

instruction  tree  Ik  that 
can  match  goal  tree  G  ♦/ 

foreachCt  of  CgmliST)!  /♦  for  each  such  tree  t  */ 


} 


ADn(RE:.[)UCE(S,G,  lk,t)  ,hEW);  /t  add  to  NEW  the  state 

created  by  reducing  goal 
tree  G  of  state  S  using  instruction 
Ik  with  commutative  form  t  ♦/ 


ret  urn (NEW);  /♦  return  list  of  new  states  derived  */ 

> 


Figure  7 ; 


Procedure  tor  deriving  new  states  from  one  goal  tree 
of  a  ciiven  state. 


4.4.  a&duclua  aaaiLcti  a&acc  mze. 


An  important  aspect  of  derivinq  code  sequences  is  the  prac¬ 
ticality  of  the  search  method  used.  If  the  search  proceeds 
blindly,  a  compinat or  la  I ly  large  search  space  is  liKely  to 
result.  Consequently,  time  and  space  considerations  associated 
with  the  actual  implementation  could  well  exceed  reasonable  limi¬ 
tations,  One  method  of  alleviating  the  problem  has  already  been 
given  and  is  obvious;  abandoning  searches  along  paths  whose 
length  estimates  exceed  that  of  the  current  solution.  However, 
this  methoci  alone  is  inadequate. 

At  each  step  of  the  search,  it  may  be  evident  that  certain 
state  derivations  are  preferable  over  others.  In  which  case,  the 
search  should  he  selective  as  to  the  state 
transitions/transformations  tnat  are  actually  performed.  As  an 
example,  suppose  we  wish  to  generate  code  for  machine  C  given  the 
following  goals: 


<- 

/  \ 

.A  + 

/  \ 

.A  .B 


<- 

/  \ 

.  B  ♦ 

/  \ 

.B  .C 


Because  location  B  is  used  as  a  source  operand  in  one  goal  and  a 
destination  operand  in  the  other,  an  intermediate  storage  loca¬ 
tion  will  he  required  it  the  goals  are  not  reduced  in  the  proper 
order.  Keeping  in  mind  that  code  is  derived  reverse  to  its  exe¬ 
cution  ordering,  the  following  illustrates  the  code  obtained 
depending  on  the  goal  tree  first  selected  for  reduction; 


left  tree  first:  mov  B,[2)  f2J:  M()nt:  =  M/B 

(  ,A<-,A+.B  )  mul  C,B  RE'STR  ICTIUNS=  ,  A  ,  ,  R  ,  ,C 

arid  [21, A 

right  tree  first:  add  0,A 

(  )  mill  C,B 

The  outcome  is  evident  after  the  first  reduction  attempts. 
Applying  *'add"  to  the  left  goal  results  in  the  following: 

<-  <-  <- 

/  \  /  \  /  \ 

.A  .A  12J  .B  ,B  ♦ 

/  \ 

•  B  .C 

The  first  sub-'goal  (.A<-.A)  can  be  removed.  The  second  sub-goal, 
however,  cannot  because  of  the  source  operand  incompatibilities. 
Since  {[21,,FU  are  incompatible  only  because  ,B  is  used  as  a  des¬ 
tination  operand  elsewhere,  a  derivation  status  code  of  "ADVKHSE” 
is  returned  for  tne  state  defined  by  the  goals: 

<-  <- 

/  \  /  \ 

C21  ,B  .B  ♦ 

/  \ 

.H  ,C 

The  status  code  "AnvERSP”  normally  indicates  source  or  destina¬ 
tion  operand  targettirv}  sub-goals  could  have  been  avoided  if 
reductions  had  been  directed  at  some  other  goal  instead.  Thus, 
attempting  to  reduce  the  right  goal  tree  (,H<-,B^.C)  as  an  alter¬ 
native  results  in  the  following  sub-goals: 

<-  <-  <- 

/  \  /  \  /  \ 

,B  ,B  ,C  .C  ,A  f 

/  \ 

,  A  .H 

The  two  sub-goals  ,B<-.F^  and  ,C<-,C  can  both  be  removed.  Since 
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no  incorripat ibi  1  ities  resulteni  from  source/destination  conflicts. 


the  reduction  attempt  Is  considered  successful  and  a  derivation 
status  code  of  "FAVORABLK”  is  returned.  The  new  state  is  defined 
by  the  single  goal: 

<~ 

/  \ 

.A  f 

/  \ 

•  A  ,R 

Obviously,  it  is  desirable  to  suppress  searching  along  paths 
which  can  only  lead  to  inferior  solutions.  The  derivation  status 
code  returned  tor  each  state  provides  the  necessary  information 
for  determining  which  paths  are  to  be  selected,  in  the  previous 
example,  the  state  derived  with  status  code  "ADVFRSF”  could  have 
been  dropped  from  the  active  search  space.  The  state  with  code 
"FAVORABLE”  would  have  been  retained,  permitting  further  searches 
along  the  paths  emanating  from  the  node  it  represents.  The 
overall  scheme,  then,  for  reducing  search  space  size  is  simple. 
At  each  step  of  the  search  a  state,  say  S,  is  selected  from  the 
active  state  list  for  further  reductions.  Let  M(S)  be  the  set  of 
new  states  derived  by  performing  reduction  attempts  on  each  goal 
tree  of  S,  Determine  what  the  best  derivation  status  code  is 
among  all  the  states  of  ^KS),  Retain  only  those  state  of  N(S) 
having  that  derivation  status  code.  Other  states  of  N(S)  pos¬ 
sessing  inferior  codes  are  removed  from  the  search  space. 

The  above  scheme  succeeds  in  reducing  search  space  size  by 
suppressing  derivation  of  inferior  code  sequences.  For  any  pair 
of  goal  trees,  the  scheme  basically  attempts  to  determine  which 
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qoal  tree  should  t)e  reiuced  first.  However,  in  some  cases  the 
reduction  ordering  may  be  irrelevant.  in  those  instances,  it  is 
also  desirable  to  reduce  search  space  size  by  suppressing  the 
derivation  ot  analogous  code  sequences. 

Analogous  code  sequences  are  those  which  use  the  same 
instructions  to  compute  the  same  results,  only  the  sequential 
orderinci  of  the  instructions  vary.  For  instance,  suppose  the  fol¬ 
lowing  goals  exist: 


<- 

/  \ 

.A  t 
/  \ 

.A  .[^ 


<- 

/  \ 

.C  ♦ 

/  \ 

.C  .R 


<- 

/  \ 

.n  ♦ 

/  \ 

.  i> 

I 

.B 


Using  the  instruction  set  of  machine  C,  six  analogous  code 
sequences  can  pe  derived; 

addB,A  addB,A  mulR,C  mulH,C  subB,D  subB,D 

mul  B,C  sub  B,D  add  B,A  sub  B,D  add  B,A  mul  H,c 

sub  B,I)  mul  B,C  sub  B,n  add  B,A  mul  H,C  add  B,A 

All  are  equal  in  terms  of  optimality.  However,  for  search  space 

size  reduction  purposes,  only  one  derivation  is  required. 

The  potential  for  deriving  analogous  code  sequences  exists 
whenever  a  state  contains  at  least  one  pair  of  goals  in  which 
either  can  be  totally  or  partially  reduced  without  any 
source/dcs t inat ion  conflicts  resulting.  Suppose  A,B  are  two  such 
goals  and  let  '-UA)  and  mchI  denote  feasible  Instructions  for 
reducing  those  goals.  Since  the  reduction  of  one  does  not  affect 
the  other#  it  is  nosslble  to  derive  two  analogous  code  sequences: 
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M  (  A  )  ;  rJ  (  H  ) 


or 

M ( B ) ;  MCA) 

To  qenerdlize,  if  a  state  contains  p  goals  which  can  be  success¬ 
fully  reduced,  then  at  least 

p  ♦  ( P  -  1  ) 

analogous  code  sequences  can  be  derived  from  that  state.  The 
problem  only  becomes  more  acute  when  several  instructions  exist 
for  reducing  a  given  goal  tree. 

Our  technique  for  suppressing  code  analogies  is  to  limit 
reductions  to  only  one  goal  tree  of  a  state.  However,  determin¬ 
ing  which  goal  tree  to  select  is  not  obvious.  Based  on  the 
characteristics  of  the  target  machine  instruction  set,  some  goals 
may  have  to  be  reduced  before  others.  Only  when  it  is  Known 
which  subset  of  goals  can  be  reduced  first,  can  one  then  be  arbi¬ 
trarily  chosen.  Such  goals,  of  course,  are  those  that  can  be 
successfully  reduced.  Indicated  py  a  derivation  status  code  of 
"FAVORABLE",  Thus,  if  one  goal  can  yield  at  least  one  new  state 
having  a  "FAVORABLE"  status  code,  and  so  can  another  goal,  then 
the  derivation  of  an  analogous  code  secnjence  will  have  been  ini¬ 
tiated,  The  basic  approach,  therefore,  is  to  limit  reductions  to 
the  first  goal  found  capable  of  yielding  at  least  one  new  state 
having  a  "FAVORARI.E"  derivation  status  code. 

Given  the  techniques  for  reducing  search  soace  size,  the 
algorithm  for  deriving  new  states  from  a  given  state  is  presented 
in  figure  H,  ft  serves  as  the  interconnection  between  the  two 
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DKRlVECS ) {  /♦  return  set  of  derivable  states  from  state  S  havinq 

ooal  trees  C,  by  attemptinq  to  minimize  the  number 
ot  qoals  reduced  ♦/ 

/*  initialize  list  tor  storing  new  states  */ 

AOD(MERGK(S),''ipw);  /♦  a  (id  new  states  derived  from  merging 

common  siib-goals  ♦/ 

liKvST_CODE<-"  ADVERSE" ;  /♦  set  best  derivation  status  code 

discovered  initially  to  lowest  value  */ 

£oreach(Gi  of  G)l  /♦  for  each  goal  tree  Gi  of  state  S  ♦/ 

it  ("'(BKST,cnDK="FAvnRABLE"  )  )  i  /*  if  previous  goals  failed 

to  produce  any  new  states  having  a 
derivation  status  code  of  '’FAVORABLE"  */ 

TEMP<-me:wST  ATES  ( s ,  Gi  ) ;  /*  derive  new  states  using  goal 

Gi  ot  state  S  t/ 

T<-GET_BEST.Cf)OECTEMP) ;  get  the  best  derivation 

status  code  of  the  states 
iust  derived  ♦/ 

ADD ( TEMP , NEW ) ?  /♦  add  the  new  states  derived  ♦/ 

if  ( T>BES r«CODE ) {  /*  reset  best  derivation  status  code 

discovered  if  required  ♦/ 

BEST«cnnE<-T; 

> 

} 

> 

foreach(Sk  ot  NEwi^  /♦  remove  any  states  derived  whose 

derivation  status  code  is 

if (D-CODE(Sk)<BEST_cnnE)  {  inferior  to  BEST.CODE  */ 

REMOVE (Sk , NEW ) ; 

} 


r  e  t  u  r  n  C  N  E  w ) ; 


> 


return  only  those  states  derived  having  the 
best  derivation  status  codes  ♦/ 


Figure  ft 


Algoritfim  for  derlvinn  new  states  by  attempting  to 
limit  reductions  to  a  single  goal. 


alqorithms  previously  alven.  That  is,  the  qeneral  heuristic 
search  procedure  FINDCOOE  (figure  6)  calls  DFRIVf:  (figure  8)  to 
return  the  list  of  states  derivable  from  the  currently  selected 
state,  DERIVE,  in  turn,  utilizes  the  routine  newsTATES  (figure 
7)  whose  action  is  to  return  the  set  of  states  derivable  from  a 
specific  goal  of  a  state.  Since  reducing  search  space  size  is 
the  objective  of  riERTVE,  it  determines  which  of  the  goal  trees 
are  to  be  used.  Its  actions  are  as  follows.  First,  states 
obtainable  by  merging  common  sub-goals,  if  any  exist,  are  added 
to  the  new  state  list.  Then,  reduction  attempts  are  performed  on 
each  goal  in  turn  until  a  goal  is  found  from  which  at  least  one 
state  can  be  derived  having  a  derivation  status  code  of  "FAVOR¬ 
ABLE”,  If  no  such  goal  can  be  found,  states  will  be  derived  from 
all  the  goals.  It  should  be  apparent  that  the  algorithm  allows 
successful  reductions  on  at  most  one  goal  tree.  Prior  to  return¬ 
ing,  all  new  states  derived  having  derivation  status  codes  infe¬ 
rior  to  the  best  discovered  arc  discarded.  In  summary,  the 
objective  of  the  procedure  is  to  return  all  successful  reductions 
of  only  one  state  goal. 

Because  the  algorithm  of  figure  8  stops  when  it  finds  the 
first  goal  that  can  be  successfully  reduced,  it  is  important  that 
the  goals  of  a  state  be  ordered.  One  reason  is  to  facilitate 
common  sub-goal  mergers.  Goals  containing  others  as  sub-goals 
should  be  the  first  ones  selected  as  reduction  candidates.  The 
logic  behind  this  is  to  confine  reductions  to  goals  that  will 
eventually  be  reduced  Into  their  sub-goal  counterparts,  thus, 


permlttlna  merqers. 


Althounh  the  reduction  of  a  sub-qodl  coun 


terpart  cannot  result  in  the  derivation  of  a  state  havinq  a 
"FAVORABLE"  Status  code,  it  is  essential  to  the  speed  ot  the 
search  that  as  few  states  be  derived  as  possible.  Hence,  the 
more  liJcely  goal  tree  candidates  should  be  selected  first.  The 
position  ot  a  goal  tree  within  a  goal  set  determines  its  reduc¬ 
tion  priority.  Those  at  the  start  have  highest  priority  since 
they  are  the  first  ones  selected,  A  second  reason  tor  maintain¬ 
ing  a  goal  ordering  scheme  concerns  reducing  temporary  storage 
needs.  It  is  desirable  to  completely  reduce  one  goal  tree  before 
attempting  reductions  on  another.  If  this  can  be  accomplished, 
temporary  storage  locations  required  for  the  one  goal  are  in 
effect  freed  and  available  for  re-use.  In  contrast,  if  several 
goals  are  only  partially  reduced,  the  temporary  locations 
required  for  each  of  those  goals  exist  at  the  same  point  in  time 
and  must  therefore  refer  to  unique  locations.  Thus,  goals  are 
also  ordered  according  to  their  size  (smaller  goals  given  higher 
priority).  However,  if  a  goal  is  contained  by  another  (is  a 
sub-tree  of),  then  the  containing  goal  will  preceed  the  sub-goal. 
It  should  be  noted  that  non-optimal  results  can  be  a  conse¬ 
quence  of  using  the  search  space  size  reduction  heuristics. 
Depending  upon  the  pecul iarl ties  of  the  target  machine  instruc¬ 
tion  set,  the  wrong  goal  tree  could  be  selected.  However,  the 
orobability  of  this  occurring  is  very  small  at  each  step  of  the 
search.  Since  considerable  reductions  in  search  space  size  are 
obtained  at  only  the  expense  of  a  small  probability  of  error,  we 


feel  the  tradeoff  involved  with  use  of  the  heuristics  is  1usti- 
f  ied. 

4.5.  IaiQuax.dj:^  aLa£.da&  aXulmlzallaa 

During  the  code  derivation  process,  unlnue  system-generated 
parameters  are  output  whenever  intermediate  storage  locations  are 
required.  Fh)rther  reductions  or  sub-goal  mergers  may  result  in 
the  binding  ol  some  of  these  parameters  to  actual  machine  loca¬ 
tions.  Those  remaining  unbound  after  a  solution  is  obtained 
denote  temporary  storage  locations  which  must  be  allocated  at 
code  generation  time,  ACT.  attempts  to  minimize  the  number  of 
temporary  storage  allocations  with  the  following  algorithm. 

First,  since  unique  system-generated  parameters  are  output 
for  each  individual  intermediate  storage  need,  it  may  be  possible 
to  reduce  the  numner  of  unique  parameters  used  by  consolidating 
compatible  temporaries.  In  essence,  the  intention  is  to  re-use 
the  same  temoorary  as  many  times  as  possible.  If  a  derived  code 
sequence  uses  n  temporaries,  each  having  common  addressability 
modes  and  disjoint  run-time  lives,  all  n  temooraries  can  be 
denoted  py  the  same  parameter.  This,  in  effect,  specifies  the 
need  to  allocate  only  one  temporary  location.  It  can  then  be 
re-used,  as  opoosed  to  allocating  n  distinct  temporaries.  An 
example  will  be  given  using  the  instruction  set  of  machine  B  to 


generate  code  tor  the  following  goals: 


<  •  <  -  <  • 


/ 

\  / 

\ 

/  \ 

,  A 

•  H 

•  C 

.C 

D 

code  obtained  is; 

LI) 

[0  J  ,  h 

[0]  : 

dlH)K  =  R 

RESTRICT  I nMS  = 

ST 

[0]  ,  A 

f  1  ]  ; 

v,0nE  =  R 

RFSTRTCTIONSr 

LD 

[13  ,C 

[21  ; 

MnOE=R 

WESTR ICTIONSr 

SI 

Cl  1  ,B 

LD 

[21 

ST 

[2  I  ,C 

Three  separate  intermediate  storage  requirements  arose  during  the 
code  derivation  process  (one  for  each  goal).  Hence,  unique 
sys tem-generated  parameters  {  f 0 ]  ,  C 1 ]  ,  C 2 1 >  were  output  for  each 
need.  However,  since  they  all  have  adciressaoi  li  ty  mode  R  and 
their  run-time  lives  are  disioint,  any  one  of  the  parameters  can 
be  used  to  replace  occurrences  ot  the  other  two.  Selecting 
parameter  [0]  as  the  candidate  results  in  the  code  sequence 
requiring  only  one  intermediate  storage  location; 

LD  C0],B  (OJ:  .M()nK  =  R  hesthictioms  = 

ST  fOJ,A 
LD  [01,C 
ST  rO),f^ 

LD  [0],0 
ST  C0],C 

In  general,  any  two  parameters  can  be  consolidated  (one 
replaced  oy  tne  other)  if  and  only  if  they  are  comoatiPle,  Com¬ 
patibility  between,  two  parameters  requires  common  addressability 
modes  exist  between  them  and  neither  be  restricted  from  replace¬ 
ment  py  the  other.  Obviously,  a  temporary  cannot  he  re-used  if 
it  is  of  the  incorrect  type.  Temporaries  having  intersecting 
run-time  lives  must  remain  as  separate  entities.  The  simultane¬ 
ous  existence  ot  two  locations  contalnina  different  values 
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necf*ssdrilY  results  in  earn  heinq  restricted  frorn  the  other  and 


thus  causing  them  to  no  incompatible. 

Another  technique  for  mlnimizinQ  temporary  storage  involves 
using  non-intermediate  storage  locations  where  possible.  That 
is,  user-detined  destination  locations  may  be  usable  lor  inter¬ 
mediate  storage  provided  they  are  used  tor  that  purpose  before 
assigned  their  final  values.  For  instance,  suppose  the  following 
goals  exist  for  which  code  is  to  be  generated  using  the  instruc¬ 
tion  set  of  rr:achine  C: 

<-  <-  <- 
/  \  /  \  /  \ 

,A  .1)  .C  ,C  .B 

The  code  sequence  derived  requires  one  intermediate  storage  loca¬ 
tion: 

mov  C,Ch]  fh]:  MODRrd/R  PFSTR  I CT  TriMS= .  B ,  .C 

mov  F^,c 
mov  [ 0 ) , B 
mov  fi ,  A 

However,  location  A  could  have  been  used  for  intermediate  storage 
purposes  since  it  is  assigned  its  value  (,0)  after  tne  run-time 
life  of  oaramoter  fOl  has  expired.  Thus,  replacing  TO]  by  .A 
results  In  the  code  sequence  requiring  no  temporaries  to  be  allo¬ 
cated: 


rn  0  V 

C,  A 

mov 

B.C 

mov 

A,B 

mov 

n ,  A 

Replacing  system-generated  parameters  by  user-defined  desti¬ 
nation  locations  is  performed  by  first  determining  which  parame¬ 
ters  are  compatible  with  which  destination  locations.  The 


compatibility  aspect  ensures  a  location  is  used  prior  to  its 


assignment  of  a  final  value  but  not  nefore  other  computations 
have  usevd  its  initial  value.  Furthermore,  some  qoal  reductions 
may  implicitly  use  a  destination  location  for  intermediate 
storage  of  sub-goal  values.  The  compatibility  check  prevents  use 
of  a  location  for  simultaneous  storage  of  two  or  more  intermedi¬ 
ate  results. 

Temporary  storage  minimization  is  performed  for  each  new 
solution  derived  auring  the  heuristic  search,  Tn  the  event  two 
solutions  are  discovered  with  both  havlna  the  same  path  length, 
the  one  requiring  fewer  temporary  storage  locations  will  be 
selected. 


4.6.  SQ.&cidl-Cd.s>£  QaI.£c:Llx^a 

Special-case  conditions  involving  operand  information  have 
previously  neen  defined  as  those  instances  where  code  optimiza¬ 
tions  exist  if  certain  assumptions  regarding  operand  values  or 
locations  can  be  made.  This  is  in  contrast  to  the  general-case 
in  which  only  operand  addressing  mode  restrictions  are  permitted. 
Special-case  conditions  can  be  formally  defined  in  terms  of  the 
search  space  used  for  deriving  code  seguences.  Suppose  trie  best 
general-case  code  sequence  derivable  for  a  Given  set  of  goals  has 
path  length  n.  then,  speria  1 -cases  are  all  the  code  sequences 
represented  by  the  paths  linking  tnc  initial  and  final  states 
Which  have  path  length  less  than  n. 


Detecting  dll  the  special-cases  associated  with  a  set  of 
goals  can  be  accomplished  using  the  heuristic  search  procedure  of 
ACG,  The  objective  of  the  heuristic  search  is  to  find  the  shor¬ 
test  path  between  the  initial  and  final  states.  If  speclal-case 
detection  is  enabled,  path  traversals  requiring  parameter  assump¬ 
tions  will  additionally  be  attempted.  However,  any  path  traver¬ 
sal  requiring  an  assumption  that  conflicts  with  the  restrictions 
imposed  upon  the  operands  involved  will  not  be  attempted.  Since 
ACG  permits  restrictions  to  be  imposed  upon  parameterized 
operands  prior  to  the  start  of  the  search  for  a  code  sequence,  a 
facility  does  exist  for  preventing  traversals  along  specific 
paths . 

An  Iterative  approach  Is  used  to  detect  (and  produce  code 
sequences  for)  all  special-cases  of  a  given  set  of  goals.  The 
user-monitor  initially  submits  the  goals  with  no  restrictions 
imposed  upon  any  of  the  parameter  operands.  In  theory#  ACG  will 
find  the  shortest  path  for  that  set  of  goals.  In  addition  to 
deriving  a  code  sequence,  ACG  returns  a  list  of  parameter  assump¬ 
tions  that  had  been  made.  Rased  upon  these  assumptions,  the  mon¬ 
itor  re-submits  the  goals,  setting  the  new  parameter  restric¬ 
tions  to  prevent  the  same  set  of  assumptions  being  made  again. 
In  terms  of  the  search  space,  these  new  operand  restrictions 
prohibit  the  same  path  being  traversed.  Since  the  objective  of 
ACG  is  to  find  the  shortest  path,  the  path  traversal  restrictions 
force  ACG  to  find  the  next  shortest  path.  Upon  finding  this  path 
and  returning  parameter  assumptions  made,  the  iterative  approach 
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of  re"suhmitt inq  the  qo<3ls  after  adcUnq  new  parameter  restrlc- 
tlons  continues  until  the  path  for  the  qeneral-case  is  traversed, 
Ttie  general-case  code  sequence  is  detected  when  none  of  the 
operands  are  replaced  bv  specific  machine  locations  or  values. 

The  iterative  approach  essentially  causes  ACG  to  find  the 
next  best  code  sequence  on  succeedlnq  Iterations,  Currently,  the 
task  of  setting  restrictions  is  the  entire  responsibility  of  the 
user-monitor  (ACG  does  not  aid  the  user),  and  care  must  be  taken 
to  ensure  the  desired  results  are  obtained,  A  recursive  scneme 
is  needed  for  setting  operand  restrictions.  Basically,  we  want 
to  prohibit  the  same  set  of  operand  assumptions  being  made  the 
second  time  around,  but  we  don't  want  to  inadvertantly  restrict 
ACG  from  solutions  which  it  has  yet  to  discover.  If  one  itera¬ 
tion  results  in  multiple  operand  assumptions,  the  operand  assump¬ 
tions  should  be  treated  separately.  That  is,  we  would  like  to 
investigate  the  possibility  of  detecting  more  spec ia 1-cases  after 
having  restricted  one  of  the  operands  but  not  the  others.  Thus, 
for  each  operand  we  recursively  investigate  special -cases  by  res¬ 
tricting  one  oarameter  but  resetting  other  parameter  restrictions 
to  their  previous  settings.  Such  a  recursive  routine  would  then 
return  when  it  derives  the  path  Identical  to  the  one  derived  by 


its  caller. 


4,7.  aaaulaLlua  ttia  ^adc.cn 


Klve  qiobdl  parriimeters  exist  for  dllowjnq  the  user  some  con¬ 
trol  over  the  search  orocess.  The  first  three  affect  processing 
time.  The  other  two  determine  the  type  of  code  sequences  to  be 
derived.  These  parameters  are  set  before  search  activity  com¬ 
mences  and  are  defined  as  follows: 

1)  BPKADTH 

bimits  the  number  of  feasible  instructions  selected  for 
attempting  reductions  on  any  one  particular  goal.  The  instruc¬ 
tions  are  ordered  according  to  the  number  of  goal  tree  nodes 
matched.  Only  the  first  PHKAOTH  number  of  instructions  are 
chosen , 

2)  Ob;  PTH 

The  maximum  allowable  search  space  patri  length.  Searches 
along  paths  whose  termination  estimates  exceed  this  value  will  be 
abandoned.  The  user  actually  sets  the  initial  minimum  value 
which  is  updated  accordinaly  as  new  solutions  are  discovered, 

3  )  SRIARCH.I.IMT  r 

Search  soace  size  limit  is  measured  in  terms  of  number  of 
states  examined.  Premature  termination  of  the  search  process 
occurs  when  this  limit  is  exceeded.  This  parameter  permits 
(ierivation  of  a  code  sequence  (not  necessarily  the  best)  within 
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reasonable  time  spans  for  complex  aoals  requirlnn  extensive 
searching  in  order  to  ascertain  the  best  solution. 

Three  types  of  search  terminations  are  possible: 

1)  normal  -  best  solution  discovered  oefore  search  space 
size  is  exceeded, 

2D  early  -  search  snace  size  Is  exceeded  and  a  solution 
exists.  Current  solution  is  returned, 

3)  early  deferreo  -  search  space  size  is  exceeded  but  no 
solution  has  been  discovered.  The  search  continues 
until  the  first  solution  is  derived, 

4)  SPKCI AL-CASK 

Flag  denoting  if  user-defined  parameters  can  be  assigned 
specific  machine  locations  or  values.  If  set,  this  parameter 
permits  handling  of  soecial-case  conditions  arising  from  the 
characteristics  of  the  target  machine's  instruction  set.  Other¬ 
wise,  only  operand  addressing  mode  restrictions  wiii  be  enforced, 

SI  EXTIME^FACTOR 

Machine  instruction  execution  time  multiplicative  factor 
permitting  regulation  of  search  space  path  lengths.  The  length 
of  a  path  is  given  by  the  eguationi 

path  length  =  1  +  (Instruction  time  ♦  KXTT  me_^PAC  FOR  I 

The  constant  t  denotes  that  a  slncUe  instruction  was  generated. 
If  EXT  1  MK^FACTf'iR  Is  set  to  0,  the  best  code  seguence  will  be 


defined  as  the  one  reauirlnq  the  least  number  of  instructions, 
□  n  the  other  extreme,  a  larqe  f'XT IMK^FAC TOR  value  directs  the 
search  for  a  code  sequence  havina  the  best  execution  time,  A 
mid-ranne  value  permits  derivation  of  code  sequences  based  on  a 
weighted  combination  of  space/time  considerations. 


4,8, 

In  this  section,  a  trace  of  the  code  derivation  process 
along  a  single  path  of  the  search  space  will  be  given.  Using  the 
instruction  set  of  machine  U,  a  code  sequence  will  be  derived  for 
the  following  goals; 

<-  <- 

/  \  /  \ 

,  A  +  ,  B  f 

/  \  /  \ 

,B  .C  ,B  ,D 

The  intent  Is  to  find  the  sequence  requiring  the  least  number  of 
instructions.  State  transitions  and  transf orm.at ions  performed  at 
each  step  will  be  shown,  Tt  should  be  Icept  in  mind  that  a  top- 
down  approach  is  used  and  code  is  derived  in  the  order  reverse  to 
its  execution. 
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TNITTAL  state 


<- 

/  \ 

•  A 

/  \ 

.H  .C 

<- 

/  \ 

•  H  ^ 

/  \ 

.B  .0 

PEST 

RES  =,c,.n 

ATTEMPTING 

'ADD'  INSTRUCTION  ON 

'  .A<-.Bf .C  ' 

DESTINATION 

OPERAND  TARGETTTNG 

REQUIRED 

<- 

[03 : 

MGDE=M/R/I  res= 

/  \ 

.A  CO] 

DKST 

RES=,C, .D 

<  ■» 

<- 

/  \ 

/  \ 

[03  + 

.R  + 

/  \ 

/  \ 

.H  .C 

•  H  ,0 

ATTEMPTING  'ST'  INSTRUCTION  ON 

<-  <- 

' , A<-t01 ' 

ST 

[03  ,  A 

/  \  /  \ 

[03  +  ,R 

[03  J 

modf:=r  res= 

/  \  /  \ 

.B  .C  .B  ,D 

DEST 

RES=,C, ,D 

ATTEMPTING  'ADD'  INSTHUfTTON  ON  '[01<-.H+,C' 


<- 

/  \ 
[01  .B 


<- 

/  \ 

[  1  .1  ,  C 


<-  ADD  tn,ro] 

/  \  ST  tO],A 

.B  + 

/  \  [03:  MnDE=R  RES= 

.H  .D  riJ;  M()DE  =  R  RES  = 


PEST  RKS=.C,. 


D 


attempting 

<- 

/  \ 

[OJ  .H 

'LD'  INSTRUCTION  ON 

<- 

/  \ 

•  B  ♦ 

/  \ 

.B  ,D 

' [1]<-.C' 

LD  [11, C 

ADD  [11, [01 

ST  (0],A 

101:  M0DE=R  PES=[11 

Cl  1 ;  MODE=R  RES=[0) 

DEST  RES=,C,.D 

ATTEMPTING 

'ADD'  INSTRUCTION  ON 

DESTINATION 

OPERAND 

TARGETTING 

REQUIRED 

<- 

I.D  [11, C 

/  \ 

ADD  [11, [01 

.B  [21 

ST  [0],A 

<• 

<- 

[01 :  MODE=R  RES=C1 1 

/  \ 

/ 

\ 

[11 :  MODE=R  RES=[01 

[21  + 

[01 

.D 

[21:  mode=m/R/i  RES= 

/  \ 

.B  .D 

DEST  RES=,C,,D 

ATTEMPTING 

'ST'  INSTRUCTION  ON 

'.B<-t21  ' 

<- 

<- 

ST 

[21  ,B 

/  \ 

/  \ 

LD 

[11  ,C 

[21  + 

[01  .B 

ADD 

[1  1  , [01 

/  \ 

ST 

[01  ,  A 

•  H  .D 

[01 : 

MODE=R 

RES= 

[11 

[11 ; 

MOOEsR 

RESs 

[01 

[21 : 

MODEsR 

RES= 

DEST 

RES=.C, 

.0 
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ATTEMPTING  'ADD'  INSTPnCTIHN  HN  't21<-.H+,n' 


<- 

/  \ 
[21  ,D 


<- 

/  \ 

[  3  ]  .  B 


<- 

/  \ 
COT  ,B 


ADD  [31, [2] 
ST  [21, B 

LD  tn,c 

ADD  ri],[01 
ST  [0],A 


ro)  : 

[13: 
[2] : 
[3] : 


MODF  =  R  RE:S=Cl),t2} 
MQDE=R  RES=C0] 

MODE  =  R  RES*[03 ,  [33 
MODE=R  RES=C23 


dp:st  res=.c,.d 


ATTEMPTING 

'LD'  INSTRUCTION  ON 

'  [23<-.D' 

<- 

<- 

LD 

[23  ,D 

/  \ 

/  \ 

ADD 

[33 , [23 

[33  ,B 

[03  .  B 

ST 

[23 

LD 

[13  ,C 

ADD 

[13 , [01 

ST 

[03  ,  A 

[03 ; 

M0DE=R 

RES=[13 , [23 

[13 : 

MODEsR 

RESs[03 

[23 : 

MODE=R 

RES=I03 , [33 

[33 : 

MODE=R 

RES=  [23 

DEST  RES=,C,,D 
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GOAL  MERGING  PERFORMED  ON  AND 


PARAMETERS  COMPATIBLE: 

' [31 '  REPLACES  * [01  * 

<- 

LD 

[21  ,D 

/  \ 

ADD 

[31 , [21 

[31  .B 

ST 

[21  ,B 

LD 

[11  ,C 

ADD 

[13 , [31 

ST 

[33  ,A 

[11 : 

MODESR 

RESs 

[33 

[21 : 

MODEsR 

RESsC33 

[31 : 

MODEsR 

RESs 

Cn  ,  [23 

DEST 

RESs.Ci 

r.D 

ATTEMPTING  'LD'  INSTRUCTION  ON 


LD  [3],B 
LD  C2],D 
ADD  [3], [21 
ST  [2],R 
LD  tlJ,C 
ADD  Cn,[3I 
ST  [31, A 

[11:  MODE=R  RES=C3] 

[21 :  MODE2R  RESsC3] 

[31 ;  MODEsR  RESs[l] , [2] 

DEST  RES=,C,.D,,B 
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GOALS  REDUCED 

ATTEMPTING  TO  MINIMIZE  TEMPf3R«\RY  STORAGE 
CONSOLIDATE  'CIJ'  AND  '[21':  'Cll'  REPLACES  '[21' 


FINAL  CODE:  LD  C3],D  [13:  MODE=R 

LD  [n,D  [33:  MCDE  =  H 

ADD  [31,  [13 

ST  [11,0 

LD  (11,C 

ADD  [13, [31 

ST  [31,  A 


The  derived  code  sequence  Is  optimal  tor  machine  B, 


4,9.  CualuaLlaa 

A  working  prototype  of  ACG  was  implemented  on  a  PDPll/50  in 
order  to  demonstrate  the  feasibility  and  practicality  of  the 
search  algorithms  proposed. 

In  most  cases  tested,  optimal  code  sequences  for  non-trlvial 
goals  were  derived.  This  is  satisfying,  since  near-optimality 
had  been  established  as  the  goal.  Examples  of  the  quality  of 
code  obtained  are  provided  in  appendix  B, 

The  search  method  used  was  effective  in  keeping  the  search 
space  to  within  a  manageable  size.  This  is  Important  as  practi¬ 
cality  and  time  efficiency  are  highly  relevant  factors.  Even  for 
non-trlvial  goals,  the  active  search  space  (those  states 
representing  uncompleted  path  nodes  requiring  storage)  normally 
numbered  under  twenty  states  at  any  given  time.  This,  in  itself, 
was  crucial  for  the  Implementation,  The  PDPll/50,  with  its 
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limited  memory,  allowed  for  only  the  simultaneous  storaqe  of 
approximately  thirty  states.  An  average  of  500  bytes  were 
required  for  a  single  state.  In  cases  where  free  storage  was 
exhausted ,  states  possessing  the  highest  termination  estimates 
would  be  discarded  to  permit  continuation  of  the  search,  A 
search  space  size  limit  (total  number  of  states  investigated)  of 
1000  appeared  sufficient.  Most  searches  terminated  prior  to 
reaching  that  cutoff  point.  The  code  sequences  in  appendix  B 
were  derived  using  a  1000  state  limit. 

In  terms  of  speed,  derivation  times  ranged  widely.  The 
average  execution  time  for  deriving  new  states  from  a  given  state 
was  approximately  1/10  of  a  second.  However,  this  varied  depend¬ 
ing  upon  the  actual  number  of  state  transitions  and  transforma¬ 
tions  that  had  to  be  performed.  Since  search  space  size  grows  at 
a  combinatorial  rate  as  goal  complexity  Increases,  derivation 
times  ranged  widely  for  complete  solutions.  Simple  goals 
required  less  than  1  second.  Complex  goals,  on  the  other  hand, 
required  over  1  minute  of  execution  time.  This  figure  is  based 
on  the  cutoff  point  though.  As  soon  as  1000  states  were  investi¬ 
gated,  the  current  solution,  if  one  existed,  would  be  returned. 
Otherwise,  the  search  continued  until  a  solution  was  found.  It 
is  felt  these  timing  figures  are  within  reasonable  limits. 
Furthermore,  it  must  be  remembered  that  the  prototype  was  imple¬ 
mented  on  a  mini-computer.  Considerable  increases  in  search 
speed  could  be  obtained  using  a  faster  machine.  The  timing  fig¬ 
ures  achieved,  however,  suggest  it  would  be  reasonable  to 
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generate  an  entire  code  generator  even  on  a  PDPll/50# 

Gf  the  three  classes  of  machines  tested,  search  complexity 
directly  related  to  the  processor  capabilities  of  each  machine. 
This  is  to  be  expected.  As  the  instruction  set  becomes  lower- 
level,  a  greater  number  of  instructions  are  required  to  reduce 
the  same  set  of  goals.  Code  searches  for  machine  A  tended  to  be 
the  most  complex.  Since  all  computations  required  the  accumula¬ 
tor  ACC,  the  problem  became  one  of  determining  the  best  goal 
reduction  ordering  to  permit  efficient  sharing  of  the  accumulator 
among  the  various  goals  that  existed.  The  sharing  problem  disap¬ 
pears  when  multiple  registers  are  available  (on  the  assumption  we 
do  not  run  out  of  registers,  a  condition  ACG  does  not  presently 
checic).  This  is  the  case  with  machine  H,  or  when  computations 
can  be  performed  directly  in  memory#  such  as  machine  C,  However# 
search  complexity  for  machine  B  is  an  order  of  magnitude  greater 
than  that  for  machine  C.  The  pre  and  post  goal  reduction  actions 
involved  setting  up  sub-goals  to  either  load  a  value  into  a 
register  or  store  the  value  held  in  a  register#  The  destination 
operand  targetting  need  causes  some  complications.  If  all  goals 
of  a  given  state  require  destination  operand  tarqetting  as  a 
prerequisite  to  goal  reduction#  each  of  the  goals  will  be  used  to 
derive  new  states.  It  is  impossible  to  determine  which  single 
goal  should  be  selected  for  operand  targettlng  without  having 
some  means  of  lookahead.  In  contrast#  because  the  destination 
tarqetting  requirement  does  not  exist  for  machine  C#  new  states 
will  be  derived  only  from  the  first  goal  found  which  can  be 
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successfully  reduced.  Thus,  the  search  space  sl^e  difference 
between  the  two  machines  Is  combinatorial. 

Search  complexity  is  obviously  related  to  goal  complexity. 
However^  goals  containing  common  sub-expressions  had  the  effect 
of  comblnator tally  increasing  search  space  size.  This  can  be 
attributed  to  the  search  procedure  exploring  all  possible  goal 
merger  combinations.  Many  combinations  may  lead  to  the  deriva¬ 
tion  of  semi-analogous  code  sequences.  Some  may  not#  Preventing 
such  combinatorial  explosions  requires  lookahead  techniques 
involving  several  steps  in  the  search  process.  Retaining  previ¬ 
ously  visited  nodes  in  the  search  space  for  this  purpose  is  gen¬ 
erally  undesirable,  at  least  from  an  implementation  standpoint. 
Possibilities  do  exist,  however,  if  the  computer  to  be  used  does 
possess  a  substantial  amount  of  core  memory, 

A  major  disappointment  was  the  inaccurate  representation  of 
Instruction  space/time  considerations.  This  resulted  primarily 
from  using  a  base  execution  time  value  for  each  Instruction, 
Depending  on  the  operand  addressing  modes  used,  an  instruction's 
execution  time  and  space  requirements  may  vary.  For  example, 
suppose  the  instruction  set  of  machine  C  is  to  be  used  to  derive 
code  for  the  following  goal: 

<- 

/  \ 

•  A  f 
/  \ 

,  r  0  ,  B 

where  ro  is  a  register 

ACG  would  derive  either  one  of  the  two  code  sequences: 
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1) 


mov  rO,A 
add  D,A 


2)  mov  8, A 

add  rO,A 

However,  supposinq  the  "mov”  and  "add"  instructions  execute  fas- 

ter  if  one  of  the  operands  is  a  register,  then  the  optimal  code 

sequence  is; 

add  B,rO 
mov  rO,A 

This  problem  could  be  alleviated.  First,  by  supplying  a  formula 
for  each  instruction  specifying  the  execution  time  based  on 
operand  addressing  modes  actually  used.  Second,  by  attempting 
other  possibilities  when  operand  compatibilities  exist.  For 
instance,  in  the  previous  example  the  "add"  instruction  had  a 
destination  operand  which  specifies  mode  M/R,  Because  of  the  M 
mode,jthe  instruction  destination  operand  is  compatible  with 
location  A,  However,  had  another  state  been  created  to  investi¬ 
gate  the  R  mode  (destination  targetting  required),  the  desired 
code  sequence  would  have  been  derived.  Unfortunately,  investi¬ 
gating  all  operand  mode  possibilities  can  only  result  in  substan¬ 
tially  Increasing  search  space  size. 

Two  other  problems  exist.  Although  they  involve  transforma¬ 
tion  of  goals  into  semantically  equivalent  forms,  they  are  worth 
noting.  Commutative  rules  are  used  but  associative  ones  are  not 
(nor  are  distributive  rules,  etc,).  Thus,  given  the  goal: 
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<- 

/  \ 

.A  + 

/  \ 

.A  + 

/  \ 

•  A  .C 

and  usinq  the  instruction  set  of  machine  C,  the  code  sequence 
derived  is; 

mov  A , [0 ] 
add  C ,  [0 ] 
mov  1 0 1  ,  A 

The  optimal  code  sequence,  however,  is: 

add  A, A 
add  C,A 

The  optimal  code  sequence  could  be  derived  but  only  if  standard 
associativity  rules  are  first  applied: 

<- 

/  \ 

.A  + 

/  \ 

.C  + 

/  \ 

.A  .A 

Furthermore,  supposlnq  an  instruction  "Inc",  which  increments  the 
contents  of  a  location  by  1,  executes  more  than  twice  as  fast  as 
the  qeneral-case  "add"  Instruction.  The  qoal: 

<- 

/  \ 

.A  f 

/  \ 

.A  2 

has  time-optimal  code: 

inc  A 
Inr  A 

ACG,  however,  would  derive  the  code: 
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add  $2, A 


The  first  attempt  at  matching: 

<- 

/  \ 

.A  + 

/  \ 

.A  2 

with  instruction  tree; 

<- 

/  \ 

[OJ  ♦ 

/  \ 

[0]  1 

results  in  the  illegal  sub-goal; 

<- 

/  \ 

1  2 

Re-defininq  the  goal  as; 

<- 

/  \ 

.A  a 

/  \ 

+  1 
/  \ 

.A  1 

solves  the  problem.  Although  these  problems  involve  tree 
transformation  equivalences  as  a  solution  (not  the  topic  of  this 
worK) ,  they  were  presented  to  illustrate  simple  optimizations 
Which  are  not  handled  by  ACG, 
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5 • t •  Xalfcaductloa 

The  automatic  code  generator 
chapters  is  far  from  complete, 
computers  were  not  incorporated, 
limitations  imposed  upon  the 
which  were  omitted  will  now  b 
suggestions  are  offered  for  futur 
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5,2,  Uata  X^ioas. 

ACG  assumed  the  existence  o 
citly,  it  was  used  as  an  integer 
could  equally  have  denoted  any  o 
poses,  the  number  of  available 
example,  it  will  be  necessary  to 
acters,  and  floating  point  numbe 
model • 

One  solution  is  the  user -de 
For  each  data  type,  the  automat 
special  syntax  for  each  to  dlffe 
programs  (goal  trees)  and  machin 
tions,  A  simple  method  Is  to  pr 
each  operand  name  to  denote  its 


t  only  one  data  type,  Impli* 
in  all  our  examples,  although  It 
ther  type.  For  practicality  pur- 
data  types  must  be  expanded.  For 
consider  integers,  bytes,  char- 
rs  simultaneously  within  the  same 

flnltion  of  abstract  data  types, 
ic  code  generator  requires  only  a 
rentiate  occurences  of  them  in 
e  Instruction  semantic  speclfica- 
epend  a  special  character  before 
type 
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For  instance! 


#A  --condition  code  operand 
$A  --  floating  point  operand 
%A  --  character  operand 

The  same  prefixing  method  can  apply  to  constants,  eg., 

S2,455  --  floating  point  constant 
#1  --  condition  code  bit 

In  the  machine  description,  all  intermediate  storage  locations 
tor  each  data  type  will  have  to  be  specified.  In  addition, 
addressing  mode  mnemonics  (eg,  M/R/I)  for  different  types  should 
be  unique  in  order  to  distinguish  between  parameter  types  and 
allow  for  multi-type  instruction  operands. 

Composite  data  types  were  also  not  treated  by  ACG,  Compo¬ 
site  data  types  include  constructs  such  as  register  pairs  or 
register  multiples.  For  pattern-matching  purposes,  it  is  neces¬ 
sary  to  treat  composites  in  terms  of  their  individual  components. 
That  is,  each  component  of  a  composite  should  be  defined  as  a 
unique  type.  Reference  to  a  composite  is  then  made  by  concatena¬ 
tion  of  the  components.  However,  difficulties  arise.  Storage 
allocation  possibilities  for  one  component  are  often  dependent 
upon  the  locations  assigned  to  the  other  components.  For 
instance,  a  register  pair  might  be  defined  in  terms  of  two  com¬ 
ponents;  an  "odd”  register  and  an  "even"  register,  where  the 
even  numbered  register  must  be  the  one  sequentially  following  the 
odd  numbered  register.  Suppose  parameters  [X],IY]  are  Initially 
generated  for  both  components  in  some  reduction  attempt.  If  one 
of  the  parameters  is  assigned  a  location  at  some  later  stage  in 
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the  derivation  process,  the  allocation  possibilities  for  the 
other  are  automaticallv  determined.  Furthermore,  parameter  res¬ 
trictions  of  one  component  may  affect  compatibility  tests  of 
other  components.  Using  the  register  pair  example  again,  if  tX3 
is  checked  for  compatibility  against  register  'rl',  but  CY]  is 
restricted  from  register  *t2*,  then  tX]  and  'rl'  must  be  deemed 
incompatible.  Otherwise,  the  assignment  forces  CY3  to  become 
'r2*  and  we  will  have  generated  incorrect  code. 

The  suggested  extensions  for  handling  multiple  data  types 
will  have  no  effect  upon  search  complexity.  Processing  time  will 
be  increased  slightly,  but  only  when  composite  data  types  are 
involved.  This  is  due  to  the  need  to  perform  operand  linJcing  and 
multiple  compatibility  tests. 

Additional  code  optimizations  may  be  possible  when  several 
data  types  exist.  Some  combination  of  data  types  may  be  define- 
able  in  terms  of  other  superset  types.  For  instance,  on  a  PDPll 
machine,  two  consecutive  bytes,  the  first  of  which  is  located  at 
an  even  address,  are  logically  equivalent  to  a  full  word  located 
at  that  same  address.  Replacement  of  subset  types  by  superset 
types  could  possibly  lead  to  the  derivation  of  better  code 
sequences.  This  can  be  exemplified  using  PDPll  words  and  bytes. 
Suppose  n  consecutive  byte  transfers  are  to  be  performed.  Nor¬ 
mally  this  requires  n  move  instructions,  one  for  each  byte,  or  a 
loop  executed  n  times.  However,  it  could  be  better  accomplished 
using  n/7  move  instructions  in  which  full  words  are  transferred 
instead.  Such  optimizations  are  beyond  the  scope  of  this  thesis. 
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5.3.  Had&s. 

ACG  currently  recognizes  three  basic  operand  addressing 
modes: 

1)  contents  of  memory  locations 

2)  contents  of  registers 

3)  constants 

Indirect  addressing  and  indexing  are  not  currently  handled. 

The  operand  syntax  used  allows  reference  to  operands  in 
terms  of  any  level  of  incUrection  or  form  of  indexing.  The  "con¬ 
tents  of"  operator  (.)  when  used  In  succession  denotes  indirect 
addressing.  Indexing  can  be  accomplished  by  applying  the  same 
operator  to  a  computable  exoresslon.  Examples: 

,,A  --  contents (contents ( A ) ) 

,(A+,B)  --  contents(A-f ,B)  or  equivalently  ACB] 

.(,B+,IfD)  --  IBM  type  of  Indexlnq  scheme 

where  H  =  base  register 
I  =  index  register 
D  =  displacement 

Required  extensions  to  ACG  are  the  following: 

1)  User  specification  of  permissable  addressing  modes#  as  dic¬ 
tated  by  the  target  machine,  and  assignment  of  mode  symbols 
(represented  internally  as  bit  positions)  for  parameter  genera¬ 
tion  purposes. 

2)  Search  algorithm  recognition  of  permissable  addressing  modes. 
In  addition,  ACG  must  consider  special  cases  where  instances  of 
operand  mode  incompatibilities  may  be  circumvented  by  treating 
unmatchable  addressing  contructs  as  normal  expressions  which  sim- 


ply  require  further  reduction.  For  instance,  suppose 


.(.X+Y) 


has  been  defined 
represents  some 
following; 

goal 


as  a  permlssable  addressing  mode#  where  X 
memory  location  and  Y  any  constant.  Given  the 


<• 

/  \ 

.A 

I 

+ 

/  \ 

C 


instruction  -  <•  [0];  memory  (.X) 

/  \  Cll!  memory  indirect (, ,X) 

fO]  [11 

the  instruction  parameter  tl]  is  incompatible  with  the  right 
sub-goal  since  the  addressability  modes  conflict.  However#  if 
the  operand  ,(,B+C)  is  treated  as  a  normal  expression#  the 
instruction  could  be  applied  to  create  the  sub-goal; 


<- 

/  \ 

tl5]  F  mode  CIS]  =  memory 

/  \  (where  CISJ  is  system-generated) 

,B  C 

In  essence#  the  following  goal  restructuring  was  performed  prior 


to  applying  the  instruction: 


<- 

/  \ 


<- 


/  \ 


•  A 


=  > 


I 

[15] 

<- 

/  \ 
[151 

/  \ 

.H  C 


The  proposed  extensions  will  have  no  effect  upon  search  com- 
plexity.  Processing  time  will  increase  since  every  expression 
corresponding  to  an  instruction  operand  will  essentially  have  to 
be  parsed  to  determine  it  it  constitutes  a  legal  operand.  The 
biggest  concern,  however,  Involves  possible  aliasing  arising  from 
indirect  operand  references.  Unless  it  is  assumed  each  indirect 
reference  pertains  to  a  unlgue  location,  highly  unoptimlzed  code 
resulting  from  numerous  “move”  instructions  is  a  likely  conse¬ 
quence,  This  is  an  important  consideration  when  code  template 
production  is  involved. 


5,4.  XQ^tj.uct.JLaa&  tdulllola 

One  of  the  more  significant  constraints  imposed  by  ACG  is 
the  limitation  of  machine  instruction  effects  to  single  processor 
state  location  values,  Each  machine  instruction  is  assumed  to 
alter  the  contents  of  one  and  only  one  location.  In  reality, 
this  is  not  always  the  case.  Some  machines,  like  the  PDPIO,  pos¬ 
sess  instructions  allowing  computed  results  to  be  placed  in  two 
separate  locations  (eg,  a  designated  register  and  a  memory 
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location).  On  many  machines,  the  result  of  an  integer  division 
takes  the  form  of  a  quotient  and  remainder  which  are  placed  in 
different  locations.  Furthermore,  most  modern  machines  permit 
condition  codes  to  be  set  as  a  side  effect  to  instruction  execu** 
tlon. 

As  a  consequence  of  assuming  Instruction  effects  are  limited 
to  single  locations,  the  search  procedure  for  deriving  code 
sequences  was  simplified.  Since  each  instruction  could  reduce 
only  one  machine  state  goal  at  a  time,  each  goal  could  be  con¬ 
sidered  separately.  Only  the  order  in  which  goals  were  reduced 
was  of  importance.  However,  if  machine  instructions  are  permit¬ 
ted  to  alter  several  locations  concurrently,  then  a  multiple 
number  of  goals  may  be  reduceable  by  any  single  instruction. 
Thus,  unless  the  derivation  process  is  modified,  it  can  no  longer 
proceed  on  an  individual  tree  reduction  basis.  It  would  have  to 
take  into  consideration  all  sets  of  goals  that  are  potentially 
reduceable  by  any  given  machine  instruction. 

One  approach  to  the  problem  involves  altering  how  feasible 
Instructions  are  selected  for  machine  state  reductions.  Previ¬ 
ously,  goal  trees  were  used  to  find  all  instructions  that  could 
reduce  them.  Using  this  approach,  it  was  possible  to  reduce 
search  space  size  by  limiting  the  derivation  process  to  only 
instructions  applicable  for  one  goal.  However,  since  multiple 
instruction  trees  are  now  involved,  this  method  cannot  be  used, 
One  could  therefore  reverse  the  procedure  and  select  goal  tree 
reduction  candidates  according  to  those  that  pattern -match  the 
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current  instruction  trees.  That  Is,  tor  each  machine  instruc¬ 
tion,  determine  which  qoal  trees  match  the  set  of  instruction 
trees  and  reduce  only  those  goals.  Certain  problems  will  be 
encountered  it  this  method  is  used: 

1)  Determining  which  instruction  trees  are  to  be  paired  with 
which  goal  trees  may  not  be  evident  as  several  possibilities  may 
exist.  For  Instance,  given  the  following: 


instruction  trees:  <-  <- 

/  \  /  \ 

COT  +  [11  4 

/  \  /  \ 
[11  [21  [01  [2] 


goals:  <- 

<- 

<- 

/  \ 

/  \ 

/  \ 

,  A  4 

,D  4 

.C  4 

/  \ 

/  \ 

/  \ 

.B  ,C 

,  A  ,C 

,A  ,D 

There  are  6  possible  pairing  combinations. 


Determining 

which  instruction 

trees  are  relevant  for 

reducing 

current  set 

of  goal  trees  may 

not  be  obvious. 

As  an 

example : 

instruction 

trees:  (11) 

(12) 

<- 

<* 

[01 : 

mudf:=m 

/  \ 

/  \ 

[11 : 

mode:=m 

[01  4 

[IJ  [21 

[21 : 

MODEsH 

/  \ 

COl  [01 


goals:  (Gl)  (G2) 

<-  <- 

/  \  /  \ 

,A  +  .B  ♦ 

/  \  /  \ 

•A  ,A  .B  ,C 


Tree  II  is  an  obvious  match  for  Gl,  but  whether  12  should  be 
paired  with  G2  is  questionable.  If  the  multiplication  instruc¬ 
tion  for  G2  requires  the  computation  to  be  performed  in  a 
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reqlster,  then  12  should  be  paired  with  C2  so  that  an  extra  move 
Instruction  (register  to  location  B)  need  not  be  generated.  Oth¬ 
erwise,  12  is  not  relevant  and  can  be  simply  treated  as  a  harm¬ 
less  side-effect  of  the  instruction  (parameter  restrictions  will 
ensure  any  storage  allocation  for  [13  will  be  a  temporary  not 
currently  in  use). 

3)  The  problems  described  by  1)  and  2)  above  require  all  possible 
tree  pairings  to  be  attempted.  This  inevitaoiy  leads  to  a  search 
space  of  comb i nat or ial  proportions. 

Extending  ACG  to  oermit  hanciling  of  multi-effect  instruc¬ 
tions  can  be  accomplished  using  another  approach  which  Is  similar 
to  the  current  method  used.  Although  this  is  an  area  requiring 
further  research  and  testing,  a  basic  outline  of  the  method  pro¬ 
posed  will  be  given. 

The  proposed  method  maintains  the  sequential  goal  reduction 
scheme  (reduction  attempts  performed  on  one  goal  tree  at  a  time). 
If  an  instruction  contains  n  trees,  and  assuming  each  tree  is  to 
be  used  to  reduce  some  goal,  the  entire  reduction  process  will  be 
performed  in  n  steps.  That  is, 

SO  =>  SI  =>  S2  =>  •••  =>  Sn-l  =>  Sn 
where  Si  (for  i=0,i,.,,,n)  represents  the  state  derived  after  the 
ith  instruction  tree  has  been  applied. 

States  SI  to  Sn-l  denote  mid-transition  states  of  the  target 
machine.  At  their  respective  stages,  the  Instruction  has  only 
been  partially  applied.  Such  states  will  be  termed  partial 
states.  States  SO  and  Sn  denote  real  machine  states  as  they 


represent  the  status  of  the  machine  before  and  after  the  instruc¬ 
tions  is  executed.  These  states  will  be  referred  to  as  complete 
states.  Partial  states  maintain  the  qoal  trees  of  SO  but  keep  a 
record  of  which  instruct ion/qoal  tree  pairings  were  formulated, 

ACG  extensions  require  complete  and  partial  states  be 
treated  differently.  Complete  states  are  identical  to  those  ACG 
currently  deals  with.  Feasible  instructions  can  be  selected  for 
them  from  amona  any  instruction  and  tor  any  goal  tree.  Partial 
states,  however,  are  mid-transition  states  after  only  one  or  more 
trees  of  some  instruction  have  been  used.  Thus,  partial  states 
are  bound  to  the  same  instruction  until  they  become  complete 
states.  Therefore,  the  selection  of  an  instruction  tree  tor  a 
partial  state  must  be  from  amonq  one  the  unused  trees  of  the 
current  instruction,  Goa  1 / Ins truct ion  trees  previously  paired 
are  ineligible  for  further  reduction  matches. 

For  each  instruction  tree  I  selected  for  reducing  qoal  G, 
two  new  states  are  created.  One  is  a  partial  state.  It  is  pro¬ 
duced  by  adding  the  pairing  {T,Gl  to  the  list  of  previous  (if 
any)  instruct ion/qoal  tree  matchings.  The  other  is  a  complete 
state  derived  by  reducing  the  current  goals  (if  destination  tar- 
getting  not  required)  using  the  instruct ion/qoal  pairings 
obtained  to  that  point  including  the  current  pairing.  Unused 
instruction  trees  must  also  be  considered  in  the  reduction  due  to 
their  side  effects.  Partial  states  in  which  no  further 
instruct ion/qoa 1  pairings  are  possible  (le,  all  feasible  trees  of 
the  current  instruction  have  been  used)  are  removed  from  the 
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search  space. 


This  approach  has  its  advantages  In  that  ACC  is  based  on 
single  goal  reductions.  It  could  easily  be  extended.  Although 
search  space  size  will  Increase,  previous  technigues  for  limiting 
reduction  attempts  to  single  goals  could  be  modified  so  that  com¬ 
binatorial  explosions  may  be  prevented.  More  importantly,  the 
duality  of  code  produced  should  not  be  affected  since  basically 
the  same  search  method  will  be  employed.  However,  because  of  the 
magnitude  of  changes  Involved,  further  research  is  required, 

5,5.  ac^aacUlxia 

The  goal  of  ACC  was  aimed  at  generating  near-optimal  code 
for  program  blocks.  No  consideration  was  given  to  programs  util¬ 
izing  any  type  of  branching.  However,  extending  ACC  to  deal  with 
branching  is  a  simple  task,  (Simple  in  the  sense  that  code  can 
easily  be  derived  for  branch  statements  but  no  attempt  whatsoever 
will  be  made  to  perform  any  type  of  branch  optimizations  such  as 
folding).  The  same  search  technique  can  be  employed  to  find  the 
best  code  sequence  for  each  individual  block  within  a  program. 
Extensions  to  the  current  model  are  required  for  finding  instruc¬ 
tion  sequences  for  the  branch  statements  that  in  effect  link  the 
blocks  together. 

First,  symbolic  labels  will  be  required  to  denote  entry 
points  of  each  block.  Labels  can  he  identified  by  names  (or 
numbers)  terminated  by  a  colon  (:).  Second,  a  new  primitive 
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operator  will  have  to  be  introduced.  It  represents  branch 

operations.  The  syntax  tor  ACG  branch  statements  can  thus  he 
defined  as  follows: 

<LAnEh>  ->  <COMD> 

where  <LAbKh>  =  some  symbolic  label 
<CO'')D>  =  any  ACG  expression 

The  above  statement  is  Internerted  as  "qoto  <LABKr,>  if  <C[)iJn>  is 
non-zero" , 

The  internal  representation  o£  programs  should  consist  of  a 
set  of  ooal  trees  for  each  individual  blocJc  (final  processor 
state  location  values  after  that  blocK  is  executed).  Branch 
statements  appear  in  sets  of  their  own.  For  example,  the  FORTRAN 
program, 

A  =  B 

C  =  D 

IF  (A.GT,C)  GO  TO  LI 
A  =  A  1 

C  =  C  +  1 

LI  B  =  A  *  C 
A  =  H  +  1 


is  represented  by 


the  followlhg  goals: 


LI 


<- 

/  \ 

•  A  4 
/  \ 

♦  1 
/  \ 

.A  .C 


<- 

/  \ 

.B  ♦ 

/  \ 

.A  .C 


<- 

/  \ 

•  A  + 

/  \ 

.A  I 


<- 

/  \ 

.C  + 

/  \ 

.C  1 


-> 

/  \ 

LI :  > 

/  \ 

.A  .C 

<-  <- 
/  \  /  \ 

.A  .B  ,c  .n 


Note  that  program  blocks  appear  in  the  reverse  order  as  they 
would  be  executed.  This  permits  compatibility  with  the  current 
search  technique  used  by  ACG,  Corresponding  code  sequence  labels 
are  output  for  the  last  instruction  generated  tor  a  set 
(equivalently  the  first  executable  instruction  of  that  set). 
Search  procedure  modifications  required  will  be: 

1)  After  the  partial  reduction  of  a  branch  tree  that  is  not  the 
target  location  of  any  other  branch  statement,  the  remaining 
sub-goals  of  the  set  should  be  combined  with  the  set  immediatedly 
below  it.  These  remaining  sub-goals  represent  calculations  that 
could  be  performed  in  the  preceeding  block.  Merging  the  two  sets 
is  important  for  facilitating  common  sub-goal  detection  and  pro¬ 
cessing  Instruction  with  multiple  effects,  hf  course,  set 
mergers  may  require  adjustment  of  destination  operand  values. 
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For  instance! 


unmerqed:  <- 

/  \ 
.A  t 


/  \ 

B  .C 


<- 

/  \ 


<- 

/  \ 

C  + 


B 


D 


/  \ 

A  ,B 


merged 


<- 

/  \ 

A 

/  \ 

.D  + 


<• 

/  \ 


<  • 

/  \ 

C  + 


0 


/  \ 

.A  .H 


/  \ 

A  .0 


2)  The  inclusion  of  an  offset  indicator  to  determine  when  branch¬ 
ing  bounds  have  been  exceeded.  For  instance,  many  machines  pos¬ 
sess  branch  instructions  effective  only  to  within  a  certain 
range.  Skip  instructions  may  require  the  target  of  a  branch  to 
be  an  exact  distance  from  the  instruction.  The  search  procedure 
must  maintain  a  record  of  all  labels  and  branch  statements  gen¬ 
erated  during  the  search  along  with  their  virtual  addresses.  The 
offset  indicator  provides  the  virtual  address  of  the  last 
instruction  generated  by  the  search.  It  is  incremented  by  the 
appropriate  amount  for  each  new  instruction  generated.  Whenever 
a  branch  statement  or  label  is  encountered,  the  offset  indicator 
provides  the  virtual  address  for  it.  The  relative  distance 
between  branch  statements  and  corresponding  target  labels  can 
then  be  checked  to  ensure  legal  code  sequences  have  been  derived. 
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3)  The  use  of  '*fake  code  blocks*' 


or 


"dummy  expressions" 


are 


required  for  constructinq  branch  statement  templates.  Such  con* 
structs  can  be  denoted  by  names  enclosed  by  square  brackets.  An 
examn le : 

Statement : 

if  tcond]  then  Cexpll  else  rexp2] 

ACG  representation: 

1.3:  texp3] 

L.  1 :  [  e  X  p  1  ] 

-> 

/  \  (the  constant  1  denotes 

L3:  1  an  unconditional  branch) 

{ exp21 
-> 

/  \ 

L 1  :  r  c  o  n  d  ] 

The  search  alqorithn  would  essentially  ignore  fake  code  blocks, 
in  that  no  code  would  be  generated  tor  them,  A  subtree  contain¬ 
ing  a  fake  code  block  would  be  reduced  by  simply  returning  its 
name,  instead  of  a  code  sequence,  and  outputting  the  appropriate 
label  if  one  exists.  At  como i le- 1 ime ,  branch  statement  templates 
would  then  be  used  In  a  recursive  manner.  Tf  a  template  contains 
fake  code  blocks,  the  actual  code  for  those  blocks  would  be  found 
prior  to  using  the  template. 

Because  search  complexity  grows  at  a  combinatorial  rate  as 
goal  complexity  increases,  multi-block  programs  could  tend  to 
become  burdensome  for  the  heuristic  search.  The  problem,  how¬ 
ever,  can  be  alleviated.  Breakpoints  can  be  set  uPr  one  at  each 


program  blocic/  so  that  the  search  does  not  continue  past  a  break¬ 
point  until  it  has  found  the  best  code  sequence  to  that  point. 
In  this  sense,  search  complexity  will  only  be  as  great  as  that 
required  for  the  most  complex  block.  Furthermore^  search  time 
will  grow  linearly  as  it  will  simply  be  the  summation  of  the 
times  required  for  each  block. 


5,6,  bLim  ImcXlad  il£.aacUlaa 

Machine  instructions  which  conditionally  alter  processor 
state  location  values  require  their  instructions  to  be  defined  in 
terms  of  combinations  of  branch  and  assignment  operations.  The 
branch  statements  define  the  conditions  under  which  the  assign¬ 
ment  operations  are  to  be  performed.  For  Instance,  a  single 
machine  Instruction  to  perform  a  block  transfer  of  tne  form 
A(I]<-B[I],  for  l=0,l,.,,,n,  and  where  n  is  the  value  of  some 
preset  register,  would  be  defined  semantically  by  the  following 
ACG  program: 

LO:  ->L1(C21<0) 

,CtOU[21)<-,(nur2])  [2]<-[2]f-l 

->L0 
LI:  [exp] 

where  [0]=address  of  target  array 
rn=address  of  source  array 
[23=index  register 

Each  program  line  denotes  a  separate  set  of  goals  (simultaneous 
equations).  Basically,  the  instruction  actions  are  repetitive, 
□ne  word  is  transferred  at  a  time,  based  on  the  current  value  of 
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the  index  register. 


I’he  index  register  is  decremented  on  each 


repetition.  Instruction  execution  terminates  when  the  register 
has  been  decremented  beyond  0,  Because  of  the  combination  of 
branch  and  assignment  operations,  instructions  of  this  type  can* 
not  be  semantically  described  by  single  sets  of  trees.  The  above 
example  required  4  sets.  The  extensions  proposed  in  section  5,4 
for  dealing  with  multi-effect  instructions  assumed  the  goal  trees 
to  be  reduced  were  all  contained  within  the  same  set.  Thus, 
further  extensions  are  required. 

The  suggested  approach  involves  partitioning  multi-set 
instructions  into  sub-instructions.  One  sub-instruction  for  each 
set  of  semantic  trees.  Say  Instruction  I  contains  n  sets,  Thenr 
the  sub-instructions  < 1 1 , 12 , , , , ,  In)  will  be  formed,  where  Tl 
denotes  the  sub-instruction  containing  the  jth  set  of  trees. 
Sub-instructions  are  linked  together  according  to  the  order  in 
which  the  sets  are  to  be  used  to  reduce  corresponding  goal  tree 
sets.  That  is: 

In  =>  In-1  =>  ,.,  =>  II 

huring  the  search,  only  the  trees  of  the  first  sub-instruction  In 
are  used  to  determine  if  instruction  1  is  a  feasible  instruction. 
If  sub-instruction  In  can  totally  reduce  the  first  set  of  goal 
trees  of  a  state,  successive  reduction  attempts  are  performed 
using  only  sub-instructions  ln-1  to  II  in  that  order  for  reducing 
the  next  n-l  sets  of  goal  trees.  The  last  sub-instruction,  II, 
need  not  completely  reduce  its  corresponding  set  since  other 
instructions  can  be  used  for  that  purpose.  Should  any  of  the 
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first  n-1  sub-instructions  fail  to  completely  reduce  their 
correspondinq  goal  tree  sets,  instruction  I  would  then  be  deemed 
an  infeasible  instruction  for  reducing  the  state. 

Given  ACG  has  been  modified  tor  handling  multi-tree  Instruc¬ 
tions,  multi-set  extensions  will  pose  no  added  problems  as  far  as 
search  complexity  is  concerned.  This  should  be  obvious.  Once  a 
multi-set  instruction  is  encountered,  further  reduction  attempts 
must  be  confined  to  the  remaining  trees  of  the  current  instruc¬ 
tion,  Only  until  success  or  failure  is  returned  will  other 
Instructions  be  permitted  to  partake  In  reduction  attempts. 
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6.  caMCLuaiuu 


In  this  thesis,  the  followincj  results  were  presented: 

(1)  a  simple  model  for  describing  machines  in  terms  of  their 
instructions  and  storage  bases 

(2)  a  heuristic  search  technique  for  converting  arithmetic 
expressions  into  near-optimal  code  sequences  for  a  large  class  of 
machines 

(3)  an  automatic  procedure  for  detecting  special-case  conditions 
associated  with  target  machine  Instruction  sets 

(4)  compiler  Interface  schemes  Involving  code  template  production 
for  entire  language  definitions 

The  machine  model  served  basically  as  a  foundation  for  the 
automatic  code  generator.  Due  to  its  simplicity,  it  is  Inade¬ 
quate  to  be  used  for  representation  of  real  machines.  For 
instance,  more  information  will  be  required  by  a  compiler  espe¬ 
cially  with  regards  to  generating  executable  binary  code.  The 
specification  of  the  internal  binary  representation  of  instruc¬ 
tions  and  operands  must  be  conveyed,  as  opposed  to  simply  provid¬ 
ing  the  symbolic  forms.  Information  required  for  interfacing 
with  operating  systems  (eg,  subroutine  calling  conventions)  will 
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also  need  to  be  Included.  For  these  reasons,  extensions  to  the 
current  model  are  necessary.  Alternatively,  other  exist Inq  but 
more  sophis t Icated  mac^iine  models  could  serve  as  a  base  for  the 
heuristic  code  qenerator.  This  is  possible  since  the  search 
alqorithms  used  are  essentially  Independent  of  the  machine  model. 
The  heuristic  search  technique  for  qeneratinq  machine- 
independent  code  represented  the  major  work  of  the  thesis.  It 
was  shown  that  heuristics  can  be  used  to  effectively  perform  the 
desired  task.  Furthermore,  code  quality  was  of  an  acceptable 
standard.  Unfortunately,  not  all  machine  architectural  features 
are  handled.  Chapter  5  presents  an  outline  discussing  those 
features  currently  lacking  and  proposes  extensions  for  dealing 
with  them.  However,  because  of  the  number  of  extensions  and 
extent  of  some  of  the  changes,  further  research  and  testing  are 
required.  Regardless  of  the  limitations,  the  overall  results  of 
the  work  are  encouraging  and  suggest  that  heuristics  can  be  suc¬ 
cessfully  used  to  overcome  tne  machine-independent  code  genera¬ 
tion  problem  in  a  feasible  and  practical  manner. 

The  automatic  procedure  for  detecting  special -case  condi¬ 
tions  was  another  major  contribution,  Much  of  the  previous  work 
relating  to  code  generator  generation  ignored  this  aspect.  Since 
code  generation  involves  machine  dependencies,  the  characteris¬ 
tics  of  the  target  machine  instruction  set  must  be  taken  into 
account,  ntherwlse,  one  cannot  hope  to  generate  compilers  that 
produce  reasonably  optimal  code.  The  importance  of  the  special- 
case  detection  procedure  to  this  work  Is  therefore  obvious. 
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Kindily,  the  true  value  of  a  code  qenerator  generator  is 


determined  by  the  performance  of  its  product.  An  evaluation  of 
the  code  produced  by  ACCI  generated  code  generators  is  required. 
This  can  be  accomplished  by  interchanging  code  generator  modules 
of  existing  compilers  with  table-driven  code  generators  capable 
of  Interpreting  ACG  templates.  Programs  would  then  be  submitted 
to  a  compiler  using  both  code  generators  and  the  resultant  code 
output  by  each  compared.  Table-driven  code  generators  capable  of 
producing  code  at  levels  near  that  of  local-optimizing  compilers 
would  prove  ACG  successful.  Since  optimizing  compilers  are  nor¬ 
mally  hand-tailored  for  specific  machi ne/ language  combinations, 
they  are  difficult  to  outperform.  An  evaluation  would  also 
uncover  faults  of  ACG  and  consequently  promote  improvements. 
Therefore,  an  in-depth  code  evaluation  study  would  additionally 
serve  as  a  valuable  enhancement  tool. 
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Appendix  A;  HACHiriE  OFSCP IPT tons 


This  appendix  describes  three  example  machines  used  in  testing 
and  demonstrating  the  automatic  code  generator  ACG,  Each  machine 
is  defined  in  terms  of  Its  available  temporary  storage  locations 
and  instruction  set. 
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MAC HI  MR  A 


A  sinqle-accumu lator ,  one-address  machine.  All 
instructions  require  use  of  the  accumulator  to 
perform  computations. 


REGISTERS:  ACC 

tp:mp  memory  locations: 

FREE  PARAMETERS:  [01 , 


TO  ,T1  ,T2  ,T3  ,T4  ,T5 

cn 


INSTRUCTION: 
SEMANTICS: 
OPERAND  MODES: 
EXECUTION  TIME: 


LD  [13 

.Acc<-rn 

rn=M/T 

0,500000 


Load  accumulator 


INSTRUCTION:  ST  tlJ 

SEMANTICS:  [1]<-,ACC 

OPERAND  MODES:  fn=M 

EXECUTION  time:  0.500000 


Store  accumulator 


INSTRUCTION:  CLR  Clear 

SEMANTICS:  ,ACC<-0 

OPERAND  MODES:  No  operands 
EXECUTION  TIME:  0.400000 


INSTRUCTION: 
SEMANTICS: 
OPERAND  modes: 
EXECUTION  TIME 


COM 

,ACC<-'^(.ACC) 
No  operands 
0.600000 


Complement 


INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME: 

INSTRUCTION ; 
SEMANTICS! 
OPERAND  MODES: 
EXECUTION  TIME: 


INC 

,  ACC<-. ACC^l 
Mo  operands 

0.700000 

DEC 

.  ACC<-. ACCt- 1 
NO  operands 
0.700000 


Increment 


Decrement 


INSTRUCTION; 
SEMANTICS: 
OPERAND  MODES: 
EXECUTION  TIME 


NEG 

.  ACC<--( , ACC) 
No  Operands 
0.700000 


Negate 
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INSTHUCTIGN : 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME: 


ASR  Shift  right 

.  ACC<-. ACC# ( 15:15), ( . ACC# ( 15:1)) 
No  operands 
0,600000 


INSTRUCTION ; 
SEMANTICS; 
OPERAND  MODES: 
EXECUTION  TIME: 


ASL  Shift  left 

.ACC<-.ACC#( 1 4:0)  ,  (0#(0:0)  ) 

No  operands 
0,600000 


INSTRUCTION; 
SEMANTICS; 
OPERAND  modes; 
EXECUTION  TIME: 


ROR  Rotate  right 

,ACC<-, ACC#(0;0) , ( . ACC# ( 15 ; 1 ) ) 
No  operands 
0,600000 


INSTRUCTION; 
SEMANTICS: 
OPERAND  MODES; 
EXECUTION  TIME; 


ROL  Rotate  left 

.ACC<-, ACC# ( 14:0) , ( , ACC# ( 1 5; 15) ) 
No  operands 
0,600000 


INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES: 
EXECUTION  TIME: 


ADD  [11 
,ACC<-,ACC+ri] 
[ 1 ) sM/T 
0.900000 


Add 


INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 


SUB  [11 
.ACC<-,ACC+-[1] 
C1]=M/I 
0.900000 


Subtract 


INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  time; 


MUL  cn 

.ACC<-.ACC»[n 

11 J=M/I 
1 ,600000 


Multiply 


INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES: 
EXECUTION  TIME; 


DIV  [11 
,ACC<-, ACC/ Cl  1 
tl]=M/I 
1.600000 


Divide 


INSTRUCTION; 
SEMANTICS: 
OPERAND  MODES; 
EXECUTION  TIME; 


MOD  cn  Modulo 

.Acc<-,Accf-(  .Acc/cn  ♦cn ) 
cn=M/i 
1.600000 


INSTRUCTION; 
SEMANTICS: 
OPERAND  MODES; 
EXECUTION  TIME: 


AND  cn 

,ACC<-,  ACC&  cn 
in  =m/t 

0,700000 


And 


I  MSTKUCTIOfJ ; 
SEMANTICS; 
OPERAND  .MnDi-:s: 
EXPXUTiniM  TIME: 


HR  CIJ 

.ACC<-.ACCI  C1  1 

[n=M/I 

0,700000 


(ir 
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MACHINE  B 


A  mul t  iTeglster ,  two-address  machine.  Except  tor  two 
instructions  ("load”  and  "store"),  placement  of  source 
operands  in  registers  is  a  necessity  prior  to 
instruction  use.  In  general,  any  of  the  available 
registers  may  be  chosen.  Exceptions  are  the  "divide" 
and  "modulo"  instructions  which  implicitly  use  register 
RO  as  one  of  their  operands. 


registers;  RO  ,R1  ,R2  ,R3  ,P4  ,R5 
TEMP  MEMORY  LOCATIONS;  TO  ,T1 
FREE  PARAMETERS;  101,  [IJ 


instruction; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 

semantics; 

OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 


LD  roi,[ii 
[0]<-Ct] 

[0]=R  fn=M/R/I 
0,500000 

ST  C1],[0] 

ro)<-[n 
[0)=M  cn=R 
0,500000 

ADD  cii,roi 

[o]<-[o]-f[n 
[o)=R  rn=R 
0,900000 

SUB  ci],ro] 

[0)<-[01+-[l J 
[0)=R  CllrR 
0,900000 

AND  C 11,1 01 
[OX-COl&Ill 
C01=R  [n=R 
0,700000 

np  in,fO] 

roj<-to] I (11 

tOlsR  [1]=R 
0,700000 


Load  register 


Store  register 


Add 


Subtract 


And 


nr 


instruct lOM : 

SEMANTICS: 

upehamd  mooks; 
EXECUTION  time: 

instruction: 

SEMANTICS: 

operand  modes: 
execution  TIME: 

INSTRUCTION: 

semantics: 

OPERAND  MODES: 
EXECUTION  time: 

instruction: 

semantics; 

OPERAND  MODES: 
EXECUTION  TIME; 

INSTRUCTION; 

semantics; 

OPERAND  MODES: 
EXECUTION  TIME; 

INSTRUCTION; 
SEMANTICS: 
OPERAND  MODES: 
EXECUTION  TIME; 

INSTRUCTION; 

semantics; 

OPERAND  MODES; 

execution  time; 

INSTRUCTION: 
SEMANTICS; 
OPERAND  MODES; 

execution  time: 

INSTRUCTION  : 

semantics: 

OPERAND  MODES; 
EXECUTION  TIME: 


MUI,  [  1  1  ,  [01  Multiply 

ro]<-[oi^[i] 

(0]=R  ClIrR 
UBOOOOO 

DIV  tn  Divide 

.R0<-.R0/ n ] 

[n=R 

1.800000 

MOD  tn  Modulo 

,RO<-.Ro+-(,Ro/[i j»rn ) 

[n=R 

1.800000 

NEC  [0] 

[()1<— to] 

tO]=R 
0.700000 

COM  [01 

[OJ<-^tOI 
[0]=R 
0.700000 

LSH  [01 

COJ<-C01#(14:0),(0#(0;0)) 
t03=R 
0.700000 

RSH  [0]  Right  Shift 

[0]<-t0i#(i5:l5),(l0]#(iS:i)) 

lOJsR 

0.700000 

LROT  [01  Deft  rotate 

[0l<-t0l#(i4;0),([0]#(is:i5)) 

[0J=R 

0.700000 

RHfiT  tOJ  Right  rotate 

fOH- [01  #  (0:0)  n  fOJ  <1  ( is:  1 ) ) 
t01=R 
0,700000 


Negate 


Complement 


Left  shift 


MACHINE  C 


A  doubleTeqlster ,  two-address  machine. 
Instructions  can  use  either  registers  or  memory 
locations  to  compute  results.  This  machine  has 
an  instruction  set  similar  to  that  ot  a  PDPli, 


REGISTERS:  rO  ,rl 

TEMP  memory  LOCATIONS:  tmoO  ,tmpl 
FREE  PARAMETERS;  [OJ,  [1] 


INSTRUCTION;  clr  [01 

semantics;  [0J<-0 

OPERAND  MODES;  [0]=M/R 
EXECUTION  TIME;  0,478500 


Clear 


INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 


com  [01 
CO] <-^[01 
[01 =M/R 
0,478500 


Complement 


INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 


inc  [0] 
[0]<-C01+l 
CO] =M/R 
0,478500 


Increment 


INSTRUCTION : 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 


dec  CO] 
[0]<-[03  +-1 
[03  =M/R 
0,478500 


Decrement 


INSTRUCTION ; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 


neq  [03 
C03<— [0] 
[03  =M/R 
0.496500 


Negate 


INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 


asr  [03  Shift  right 

[03<-[03#(15;15),([03#(15;t)) 
t03  =M/R 
0,478500 


INSTRUCTION: 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 


asl  [01  Shift  left 

f  01  <-[01  « (1  4:o) ,  (0M0;0) ) 

[  0  1  =  M  /  R 
0,478500 
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instruction ; 
semantics; 

OPERAND  MODES; 

execution  time; 

INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION: 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 

semantics; 

OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION! 
SEMANTICS; 
OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION; 

semantics; 

OPERAND  MODES; 
EXECUTION  TIME; 

INSTRUCTION ; 

semantics; 

OPERAND  MODES; 
EXECUTION  TIME; 


ror  [0]  Rotate  rlqht 

tO] <-[0] # (0:0) , ( tO] #( 15: 1 ) ) 

10] =M/R 
0.478500 

rol  CO]  Rotate  left 

[0]<-C01#(14;0),(C0]#(15;15)] 
CO] =M/R 
0.478500 

swab  [0]  Swap  halves 

t0]<-C0]#(7;0),([0]«C15:8)) 

CO J=M/R 
0.478500 


mov  C  n  »  CO  1 

co]<-cn 

C0]=M/R  C1]=M/R/I 
0.717000 


Move 


add  CllrCOJ 
C0]<-C01+C11 
C0]=M/R  CllsM/R/T 
0.767500 


Add 


sub  Cl), CO] 
[0J<-C0)+-Cn 
C0J=M/R  C1]=m/r/i 
0.767500 


Subtract 


mul  C I )  ,  CO] 
C0]<-C0]^C11 
[0]=M/R  Cn=M/R/I 
0.985000 


Multiply 


div  cn,coi 

C0J<-C0]/fl] 
C0]rM/R  ril=M/R/I 
0.985000 


Divide 


rnod  Cl],  CO]  Modulo 

[01<-C0]4-(C01/C11*C11) 
[0]=M/R  Ct]=M/R/I 
0.985000 


blc  cn,io] 
t0]<*C0]&’^Cl] 
[0]=M/R  Cn=M/R/I 
0.767500 


And  (with  one  operand 
complemented) 
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I N STRUCT lOM: 
SEMANTICS: 
nPERAND  MODES: 
EXECUTION  TIME: 

INSTRUCTION: 
SEMANTICS: 
OPERAND  MODES: 
EXECUTION  TIME: 


bis  1 1 ] ,  [01  Or 

[oj<-roi  I  [11 

[OlsM/R  Cn=M/R/I 
0.767500 

xor  111,  [01  Exclusive  or 

[0]<-[0l&^tll  I  (i:[0]&[l] ) 

[0J=M/P  [11=M/R/I 
0,767500 


Appendix  O:  CflDK  DEPIVATIOM  EXAMPLP:S 

Code  sequences  derived  for  the  machines  ot  appendix  A  appear  on 
the  followinq  paqes.  The  goals  selected  represent  non-trivial 
cases.  Goal  restructuring,  common  sub-expression  handling,  and 
use  of  variables  as  temporaries  were  factors  which  had  to  be 
taken  into  account,  A  search  space  size  limit  of  1000  was  used, 
tn  some  cases,  early  search  terminations  prevented  the  generation 
of  optimal  sequences.  The  search  space  size  was  not  extended  for 
the  purpose  of  showing  the  quality  of  code  obtained  when  reason¬ 
able  search  limitations  are  enforced. 


Simulated  compile-time  storage  allocation  was  performed  for  all 
of  the  examples.  The  execution  time  multiplicative  factor  used 
in  the  search  was  set  at  1,0, 
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A<- ,  B  +  ,C 


.B<-,  A+.C 


An  interchdme  of  values  with  the  addition  of  a  common 
variable.  One  temporary  will  automat i ca 1 1 v  be 
required. 


Machine  A 


Machine  n 


Machine  r 


Code ; 


States : 


LD 

A 

LD 

RO  ,  A 

mov 

B,r0 

ST 

TO 

LD 

K2,C 

mov 

A,r 

LD 

C 

ADD 

H2,P0 

mov 

r  0 ,  A 

ADD 

B 

LD 

R1  ,B 

add 

C,B 

ST 

A 

ST 

RO  ,  B 

add 

C,A 

LD 

TO 

ADD 

R1  ,R2 

ADD 

C 

ST 

R2,A 

ST 

B 

121 

1  07 

14 

Optimal  code  is  qenerated  for  machines  A  and  B,  A 
ignores  the  common  value  C  while  B  re-uses  the  value 
it  loaded  in  register  R2,  Code  for  machine  C  is  the 
minimum  number  of  instructions  for  the  operation  but 
could  have  performed  one  of  the  additions  in  a  register. 
Since  the  machine  description  does  not  specify  that 
speed  increases  exist  when  registers  are  used,  this  code 
is  considered  optimal. 


1  3b  - 


. A<-.B+.C+%%% 


.R<-,H+.C4, A 


where  %%%  =  .ACC  for  machine  A 
s  .RO  tor  machine  B 
=  .rO  for  machine  C 


A  common  sub-expression  and  one  temporary  initially 
containing  a  required  value.  Since  A  is  used  as  a  source 
and  destination  operand,  the  order  in  which  the  goals  are 
reduced  is  of  importance. 


Machine  A 


Machine  B 


Machine  C 


Code; 


ST 

TO 

LD 

R2,C 

add 

C,B 

LD 

B 

LD 

R1  ,B 

mov 

B,rl 

ST 

T1 

ADD 

R1  ,R2 

add 

A,h 

ADD 

C 

LD 

R1  ,  A 

mov 

rO ,  A 

ADD 

A 

ADD 

R2,R1 

add 

r  1 ,  A 

ST 

B 

ST 

R1  ,B 

LD 

TO 

ADD 

R2,R0 

ST 

A 

ST 

RO,  A 

LD 

T1 

ADD  C 
ADD  A 
ST  A 

States ; 

1000  482  67 


Code  for  A  is  non-optimal,  attributable  to  the 
premature  termination  of  the  search  (1116  states 
were  needed).  Code  for  machine  D  is  optimal  ••  the 
computed  value  of  the  common  sub-express ion  is  re-used. 
Code  for  C  should  have  used  1  less  reaister  and 
instruction.  Experimental  destination  tarqetting 
would  have  to  have  been  attempted  by  ACG  in  order 
to  generate  the  optimal  sequence. 
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. A<-.H 


.n<-.c 


.C<-.A 


A  triple  interchange  of  values.  The  aim  is  to  minimize 
temporary  usage. 


Machine  A 


Machine  B 


Machine  c 


Code : 


States : 


LD 

A 

LO 

R0,C 

mov 

A ,  ro 

ST 

TO 

LD 

R1 

mov 

B,A 

Lr.) 

H 

ST 

RO  ,B 

mov 

C,B 

ST 

A 

LD 

RO,  A 

mov 

rO,C 

LD 

C 

s  r 

R1  ,  A 

ST 

B 

ST 

R0,C 

LD 

TO 

ST 

C 

613 

76 

?1 

Optimal  code  generated  for  each  machine. 
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,A<’",r)+,E 


B<* , D+  ,  E 


•  C  <  -  •  I) 


•E<-.C+,A 


.D<-* A 


A  coiTiplex  set.  of  equations  --  common  sub-expressions, 
common  variables,  and  usage  of  variables  as  both  source 
and  destination  operands* 


Machine  A 


Machine  B 


Machine  c 


Code ; 


LI) 

c 

LD 

R2,C 

mov 

E,p 

ST 

B 

LD 

R0,D 

mov 

C  ,E 

LD 

D 

ST 

R0,C 

mov 

D,r 

ST 

C 

LD 

R1  ,E 

add 

D,B 

LD 

A 

ADD 

R0,R1 

mov 

A,D 

ST 

D 

LD 

RO,  A 

add 

a,e 

LD 

C 

ST 

R1  ,  A 

mov 

B,  A 

ADD 

E 

ST 

P0,D 

ST 

A 

ADD 

R2,R0 

T.D 

B 

ST 

R0,E 

ADD 

D 

LD 

RO,  A 

ST 

f; 

ST 

R0,B 

LD 

A 

ST 

B 

1000 

1  000 

1  000 

Early  search  termination  for  machines  A,B  prevented  ACG 
from  finding  the  correct  evaluation  ordering  --  2  less 
Instructions  were  required  for  A,  1  less  for  H  (search 
space  size  limits  were  still  exceeded  even  with  a 
limit  of  5000  states).  However,  In  both  cases, 
an  ordering  which  minimizes  temporary  storage  was 
found.  For  machine  A,  no  temporaries  need  to  be 
allocated.  Tills  is  In  Itself  a  major  feat  since  It  has 
only  one  accumulator  which  must  be  used  for  all 
computations.  Code  for  machine  C  is  optimal.  The  use 
of  user-destination  locations  tor  temporary  storage  is 
illustrated  by  this  example. 
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,A<-, Af .B 


,  B  <  -  ,  A  +  •  0 'h  .  C 


•  C  ^  •  A 


P'.mbedded  common  sub-expressions. 


Machine  A 


Machine  B 


Machine  C 


Code : 


States : 


LD 

A 

LD 

F2,C 

mov 

B,r0 

ST 

TO 

LD 

RO,  A 

mov 

C,B 

ADD 

D 

ST 

R0,C 

mov 

A,C 

ST 

A 

LD 

Rl  ,B 

add 

rO,A 

ADD 

C 

ADD 

R0,R1 

add 

A,B 

ST 

B 

ST 

Rl  ,  A 

LD 

TO 

ADD 

Rl  ,R2 

ST 

C 

ST 

R2,B 

1000 

1000 

SR 

Optimal  code  in  each  case,  despite  two  of  the  searches 
terminatinq  prematurely,  Note  how  the  evaluation 
ordering  differs  for  each  machine. 
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.B<-, A 


.C<-,D 


.D<-.A 


IntercBaaq i nq  and  transferring  two  values. 


Machine  A 


f^achlne  B 


Machine  C 


Code ; 


LD 

A 

LD 

R0,B 

mov 

B,C 

ST 

D 

ST 

R0,C 

mov 

A,B 

LO 

3 

T.D 

RO  ,  A 

mov 

C  ,  A 

ST 

A 

ST 

R0,B 

mov 

B,D 

LD 

D 

ST 

R0,D 

ST 

B 

LD 

R0,C 

LD 

A 

ST 

RO,  A 

ST 

C 

• 

• 

1  000 

1000 

1  39 

H:arlY 

termination  for 

machines  A 

,B  resulted  in 

non-optimal  code 

being 

generated 

(machine 

A 

required  '3671  states. 

251  S 

for  machine  B) 

•  One 

less  Instruction 

could 

have 

been 

used  in 

both 

cases , 

although 

machine  B  would 

require  use  of 

another  register 

,  The 

code 

,  however,  is 

near- 

optimal  and  does  minimize  temporary  storage. 
Code  for  machine  C  is  optimal. 
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.A<-.B+.C 


The  same  computation  assigned  to  3  variables. 


Machine  A 


Machine  B 


Machine  C 


Code: 


States : 


LD 

C 

LD 

PI  ,C 

add 

B,C 

ADD 

B 

LD 

RO  ,B 

mov 

Cr  A 

ST 

A 

ADD 

R0,R1 

mov 

C,B 

ST 

B 

ST 

R1  ,  A 

ST 

C 

ST 

HI 

ST 

HI  ,C 

61S 

1  000 

1  07 

Optimal  code  aenerated.  Goal  reduction  ordering  is 
an  important  factor  for  machine  C, 


.E<-.D 


,C+,  A+.E 


Another  complex  set  of  qoals 


Machine  A 


Machine  B 


Machine  c 


Code ; 


States : 


LD 

D 

LD 

R0,D 

mov 

£,r0 

ST 

TO 

LD 

R2,E 

mov 

D,E 

hD 

C 

ST 

R0,E 

mov 

r0,D 

ADD 

H 

LD 

PI  ,C 

mov 

A ,  ro 

ADD 

A 

LD 

R0,B 

mov 

C,  A 

ADD 

K 

ADD 

R0,R1 

add 

B,A 

ST 

D 

LD 

RO,  A 

add 

A,r0 

LD 

TO 

ST 

R1,A 

add 

rO  ,D 

ST 

E 

ADD 

R1  ,R0 

LD 

C 

ADD 

R2,R0 

ADD 

R 

ST 

R0,D 

ST 

A 

1000 

1000 

99 

Code  for  machines  A  and  B  is  optimal  (althouah 
search  limits  were  exceeded)*  Because  of  the  limited 
register  storage  of  machine  A,  optimal  code  Is  only 
possible  if  the  common  sub-expression  B+C  is  ignored. 
The  converse  holds  true  for  machine  B,  Code  for 
machine  C  misses  the  optimal  sequence  by  1  instruction. 
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.  A<-  ,  A-f  , 


*D^*»A'^*A 


Computations  involvina  repeated  use  of  the  same 
source  operand. 


Machine  A 


Machine  B 


Machine  C 


Code ; 


States ; 


LD 

A 

l.D 

PO  ,  A 

ADD 

A 

ADD 

PO  ,  RO 

ST 

A 

ST 

PO,  A 

ST 

B 

ST 

R0,D 

83 

101 

add  A, A 
mov  A,D 


23 


Each  sequence  is  optimal.  For  machines  A  and  R 
is  pertinent  they  load  the  source  operand  only 
The  important  factor  for  machine  C  is  the  qoal 
reduction  ordering. 


r  it 
once , 
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s 


Matching  instructions  related  to  'f'  operations. 


Machine  A 


Machine  B 


Machine  C 


Code : 


States 


LL) 

D 

LD 

PO  ,D 

mov 

B,  A 

INC 

LD 

R1  ,$1 

sub 

C,  A 

ST 

D 

ADD 

R0,R1 

inc 

D 

LD 

R 

ST 

R1  ,D 

SUB 

C 

LD 

R0,C 

ST 

A 

LD 

Rl 

SUB 

R0,R1 

ST 

R1  ,  A 

57 

74 

1  3 

Optimal  code.  Subtract  instructions  output  for 

operator  combination.  For  machines  A  and  C, 
the  faster  increment  instruction  is  generated  tor 
D+1  (machine  B  does  not  have  such  an  instruction). 


14S 


.A<-("'.  A&.IO  !•',€ 


.C<-0 


Matchina  other  instructions. 


Machine  A  Machine  B  Machine  c 


Code : 

LD 

A 

LD 

RO,  A 

mo  V 

B,rO 

COM 

COM 

RO 

b  ic 

A ,  rO 

AND 

H 

LD 

R1  ,B 

mov 

C,  A 

ST 

A 

AMD 

P0,R1 

com 

A 

LD 

C 

LD 

HO,C 

bis 

rO ,  A 

COM 

COM 

RO 

clr 

C 

OR 

A 

UP 

R1  ,H0 

ST 

A 

ST 

RO,  A 

CLH 

LD 

R0,$0 

ST 

C 

ST 

R0,C 

States : 

781 

112 

43 

Optimal  sequences  generated.  The  assignment  of  0 
to  variable  C  is  performed  last  in  each  case  so 
that  temporary  storage  can  be  re-used  (machines  A 
and  B)  or  omitted  (machine  C), 
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Mixed  operations  involvinq  re-usable  source  operand 
values • 


Machine  A  Machine  B  Machine  c 


Code : 

LD 

B 

LD 

H2,A 

mov 

B,E 

COM 

LD 

R1  ,A 

xor 

A,E 

AND 

A 

COM 

R2 

com 

E 

ST 

K 

LD 

R0,B 

LD 

A 

AND 

R0,R2 

COM 

COM 

RO 

AND 

B 

AND 

R0,R1 

OR 

F 

OR 

HI  ,H2 

COM 

COM 

R2 

ST 

E 

ST 

H2,F. 

States : 

165 

1  94 

10 

All  produce  optimal  code.  For  machines  A  and  C, 
location  E  is  used  for  temporary  storage  prior  to 
its  assignment  of  a  final  value.  For  machine  B, 
the  value  held  in  HO  is  re-used  instead  of  re-loaded. 
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.A<-,A»,H  .B<-.A*,B+,C 


Mixed  operations  with  common  sub-expressions. 


Machine  A 


Machine  B 


Machine  c 


Code : 


States 


LD 

B 

LD 

R1  ,P 

mu  1 

B,  A 

MUL 

A 

LD 

RO,  A 

mov 

A,B 

ST 

A 

MUL 

R0,R1 

add 

C,B 

ADD 

C 

LD 

R0,C 

ST 

P 

ST 

R1  ,  A 

ADD 

R1  ,R0 

ST 

RO,H 

63 

214 

25 

Optimal  code  for  each.  For  machines  A,B,  the 
common  sub-expression  Is  not  re-computed  or 
re-loaded.  For  machine  C,  the  generation  of  a 
temporary  was  prevented  by  computing  the  value 
in  location  A  first,  then  transferring  the 
common  sub-expression. 
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.A<-, At.B/.C 


.P<-.H+-( .C*( .B/,C) ) 


Division  operations  --  machine  B  requires  the  use  of  a 
designated  register  (RO), 


Machine  A  Machine  B  Machine  C 


Code ; 

w 

B 

LD 

P0,B 

mov 

B,D 

MUL 

A 

LD 

Rl  ,A 

mod 

C,D 

DI  V 

C 

MUL 

R1  ,R0 

mul 

B,  A 

ST 

A 

LD 

Rl  ,C 

di  V 

C,  A 

LD 

P 

DIV 

Rl 

MHO 

C 

ST 

RO,  A 

ST 

D 

LD 

R0,B 

MOD 

Rl 

ST 

R0,D 

States : 

93 

1000 

1 1 

Each  code  sequence  Is  optimal.  For  machine  B, 
needless  register  transfers  are  prevented  by 
ensuring  the  source  operands  for  the  division  and 
modulo  operations  are  computed  or  loaded  using  the 
proper  registers.  Furthermore,  the  value  C, 
required  in  both  expressions,  is  loaded  only  once 
(in  register  Rl). 


149 


Appendix  c:  CODE  TEMPLATES 


Code  templates  for  the  machines  of  appendix  A  are  illustrated  on 
the  following  pages.  Three  goals,  denoting  typical  language 
operations,  were  used  as  input  to  ACC..  Templates  for  the  first 
special-case  detected  and  for  the  general-case  are  shown. 
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machine:  a 


ro]<-tn 


CODE  template  Special-case;  ,ACC<-0 

Operand  map: 

[tl  (mode  M/R/1)  ->  0  (mode  I) 

CO]  (mode  M/R/I)  ->  ,ACC  (mode  R) 

Temporary  locations  required; 

None 

Locations  implicitly  required: 

None 


Code; 


CLP 


CODE  template  General-case 

Operand  map; 

tl)  (mode  M/R/i)  ->  rn  (mode  M/I) 

[0]  (mode  M/P/I)  ->  [0]  (mode  M) 

Temporary  locations  required: 

None 

Locations  implicitly  required: 

.ACC 

Code ; 

LD  Ct) 

ST  CO) 


ISl 


CODE  TEMPLATE 

Special 

-case:  •ACC<-. 

ACC41 

Operand  map: 

[2] 

(mode 

M/R/n 

-> 

1  (mode  I) 

[13 

(mode 

M/H/n 

-> 

•  .ACC  (mode 

R) 

[03 

(mode 

M/R/I ) 

-> 

•ACC  (mode 

R) 

Temporary  locations  required: 
None 


Locations  Implicitly  required: 
None 


Code : 

INC 


CUDE  template 


General-case 


Operand  map: 


[23 

(mode 

M/R/I ) 

-> 

[23 

(mode 

M/I  ) 

[13 

(mode 

M/R/I) 

-> 

[13 

(mode 

M/I  ) 

[03 

(mode 

M/R/I) 

-> 

[03 

(mode 

M) 

Temporary  locations  required: 
None 

Locations  implicitly  required; 
•  ACC 

Code : 


LD 

[23 

ADD 

[13 

ST 

[03 

\b7 


fo]<-(tn/[2j)+-r3] 


code:  template:  special-case:  ,  ACC<-(  .ACC/[2]  )+-l 

Operand  map: 


[3J  (mode  M/R/n 

-> 

1  (mode  1) 

C2]  (mode  M/R/I) 

-> 

(2)  (mode  M/I) 

(11  (mode  M/R/I) 

-> 

.ACC  (mode  R) 

(01  (mode  M/R/T) 

-> 

.ACC  (mode  R) 

Temporary  locations  required: 

None 

Locations  implicitly  required: 

None 

Code : 

D 1 V  [  2  ] 

DEC 


CODE  template 

General-case 

Operand  map; 

(31  (mode 

M/R/I ) 

-> 

(33 

( mode 

M/I) 

(21  (mode 

M/R/I ) 

-> 

(23 

( mode 

M/I) 

(11  ( mode 

M/R/I ) 

•*  > 

f  1 1 

( mode 

M/I  ) 

(0)  (mode 

M/R/I ) 

-> 

(0) 

( mode 

M) 

Temporary  locations  required: 
None 

Locations  implicitly  required: 
.ACC 

Ll> 

(13 

DIV 

(23 

SUB 

(3) 

ST 

(0) 

Code 


MACHINE  B 


[0]<-tl] 


s 


NO  SPECT AL-CASES  FOUND 


CODE  TEMPLATE 

(leneral-case 

Operand  map: 

til  (mode 

M/R/I 1 

->  111 

(mode 

M/R/I) 

CO]  (mode 

M/R/T ) 

c 

A 

1 

(mode 

R) 

Temporary  locations  required: 
None 


Locations  implicitly  required: 
None 


Code: 


hi) 


[0] ,  tn 


[0]<-rl3-^^2] 


0 


II 

II 

li 

II 

II 

II 

li 

li 

II 

II 

II 

II 

II 

II 

11 

11 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

11 

II 

II 

II 

II 

NO  SPFXIAL- 

•CASES  FOUND 

CODK  TEMPLATE  General-case 


Operand  map: 

[21  (mode  M/R/I) 

C13  (mode  M/R/I) 

[OJ  (mode  M/R/i) 

->  [21  (mode  R) 

->  (01  (mode  R) 

->  (01  (mode  R) 

Temporary  locations  required: 
None 

Locations  implicitly  required: 
None 

Code : 

ADD  [21,  [01 

1S5 


[01<-( ri]/(2] )+-C3] 


CODE  TEMPLATE 

Special 

-case:  , 

X  1 

O  1 

A  1 

•  1 

1 

a  1 

HO/[23 )+-[33 

Operand  map: 

[33  (mode 

M/R/i) 

•  > 

(33 

( mode 

R) 

(23  (mode 

M/H/n 

-> 

(23 

( mode 

R) 

(13  (mode 

M/R/r ) 

-> 

.PO 

(mode 

R) 

[03  (mode 

M/H/I ) 

-> 

.HO 

( mode 

H) 

Temporary  locations  required: 
None 

Locations  Implicitly  required: 
None 

Code : 

DIV  [23 

SUB  [3 3, HO 


CODE  TEMPLATE  General-case 

Operand  map: 


[33 

(mode 

M/H/I) 

-> 

[33 

(mode 

R) 

(23 

(mode 

M/R/I) 

-> 

[23 

(mode 

R) 

(13 

(mode 

M/R/I) 

-> 

[13 

(mode 

M/H/I ) 

[03 

(mode 

M/R/I) 

-> 

[03 

(mode 

R) 

Temporary  locations  required: 
None 

Locations  implicitly  required: 
.HO 

Code : 


LD 

HO,  n  3 

DIV 

[23 

LD 

[03 ,R0 

SUB 

[33 , [03 

156 


MACHINE  C 


[0J<-[1 ] 


CODE  TEMPLATE  Spec ial -case :  [0]<-0 

Operand  map: 

(1]  (mode  M/R/I)  ->  0  (mode  I) 

CO]  (mode  M/R/l)  ->  [0]  (mode  M/R) 

Temporary  locations  required: 

None 

Locations  implicitly  required: 

None 


Code : 


clr 


CO] 


CODE  TEMPLATE  General-case 

Operand  map: 

Cn  (mode  m/R/i)  ->  Cl]  (mode  M/R/I) 

COJ  (mode  M/R/I)  ->  CO)  (mode  M/R) 

Temporary  locations  required: 

None 

Locations  implicitly  required; 

None 


Code ; 

mov  1 1 J ,  [01 
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rO]<-[l ]f  [23 


£3  = 


CODK  TFMPLATE 


Special-cdse :  [0]<-[0]'»-l 


Operand  map: 

C23  (mode  M/R/I) 
[13  (mode  m/R/I) 
[03  (mode  M/R/T) 


->  1  (mode  I) 

->  [03  (mode  M/R) 

•>  [03  (mode  M/R) 


Temporary  locations  required: 
None 

Locations  implicitly  required: 
None 


Code : 

inc  103 


CODE  TEMPLATE  General-case 

Operand  map: 


[23 

(mode 

M/R/I ) 

-> 

[23 

(mode 

M/R/I) 

[13 

(mode 

M/R/I ) 

-> 

[03 

( mode 

M/R) 

[01 

(mode 

M/R/I) 

-> 

[03 

(mode 

M/R) 

Temporary  locations  required: 
None 

Locations  implicitly  required: 
None 


Code : 

add  [23,  [03 
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ro]<-( tl]/[2] )+-f31 


CODE  template 

Special 

-case ; 

[01<-( [03/[23 )+ 

Operand  map; 

[33  (mode 

M/R/I  ) 

-> 

1  (mode  I) 

[23  (mode 

M/R/I) 

-> 

[23 

(mode  M/R/1) 

[13  (mode 

M/R/I ) 

•  > 

[03 

(mode  M/R) 

roj  (mode 

M/R/T) 

•> 

[03 

(mode  M/R) 

Temporary  locations  required: 
done 


Locations  implicitly  required; 
None 

Code ; 

div  [23, [01 

dec  [OJ 


CODf:  template;  neneral-case 

Operand  map; 


C3J 

( rn  0  d  e 

M/R/T ) 

-> 

[31 

( mode 

M/R/I) 

[23 

(mode 

M/R/1  ) 

-> 

[23 

(mode 

M/R/I) 

(13 

(mode 

M/R/n 

-> 

roi 

( mode 

M/R) 

[03 

( mode 

M/R/I ) 

-> 

C03 

( mode 

M/R) 

Temporary  locations  required; 
None 

Locations  implicitly  required; 
None 

Code : 

div  [23,  [01 

sub  [ 3  3 , CO  3 
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W.R.  Lalonde,  February  1971 
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*  CSRG-12  THREE  DIMENSIONAL  DATA  DISPLAY  WITH  HIDDEN  LINE  REMOVAL 

Rupert  Bramall,  April  1972 
[M.Sc.  Thesis.  DCS.  1971] 

*  CSRG-13  A  SYNTAX  DIRECTED  ERROR  RECOVERY  METHOD 
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[M.Sc.  Thesis.  DCS,  1972] 

CSRG-14  THE  USE  OF  SERVICE  TIME  DISTRIBUTIONS  IN  SCHEDULING 
Kenneth  C.  Sevcik,  May  1972 

[Ph.D.  Thesis,  Coriirnittee  on  Information  Sciences, 

University  of  Chicago,  1971;  JACM,  January  1974] 

CSRG-15  PROCESS  STRUCTURING 

J. J.  Horning  and  B.  Randell,  June  1972 
[ACM  Computing  Surveys,  March  1972] 

CSRG-16  OPTIMAL  PROCESSOR  SCHEDULING  WHEN  SERVICE  TIMES  ARE 

HYPEREXPONENTIALLY  DISTRIBUTED  AND  PREEMPTION  OVERHEAD 
IS  NOT  NEGLIGIBLE 
Kenneth  C.  Sevcik,  June  1972 

[Proceedings  of  the  Symposium  on  Computer-Communication, 
Networks  and  TeletrafRc,  Polytechnic  Institute  of  Brooklyn,  1972] 

*  CSRG-17  PROGRAMMING  LANGUAGE  TRANSIJ^TION  TECHNIQUES 

W.M.  McKeeman,  July  1972 

CSRG-18  A  COMPARATIVE  ANALYSIS  OF  SEVERAL  DISK  SCHEDULING  ALGORITHMS 
C.J.M.  Turnbull,  September  1972 

CSRG-19  PROJECT  SUE  AS  A  LEARNING  EXPERIENCE 

K. C.  Sevcik  et  al,  September  1972 
[Proceedings  AFIPS  Fall  Joint  Computer  Conference, 

V.  41,  December  1972] 

CSRG-20  A  STUDY  OF  LANGUAGE  DIRECTED  COMPUTER  DESIGN 
David  B.  Wortman,  December  1972 
[Ph.D.  Thesis.  Computer  Science  Department, 

Stanford  University.  1972] 

CSRG-21  AN  APL  TERMINAL  APPROACH  TO  COMPUTER  MAPPING 
R.  Kvaternik,  December  1972 
[M.Sc.  Thesis.  DCS,  1972] 

*  CSRG-22  AN  IMPLEMENTATION  LANGUAGE  FOR  MINICOMPUTERS 

G.G.  Kalmar,  January  1973 
[M.Sc.  Thesis,  DCS,  1972] 

CSRG-23  COMPILER  STRUCTURE 

W. M.  McKeeman,  January  1973 

[Proceedings  of  thi^  USA-Japan  Computer  Conference,  1972] 


-  3- 


•  CSRG-24  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROCr^M 

ENGINEERING 

J.D.  Gannon  (ed.).  March  1973 

CSRG-25  THE  INVESTIGATION  OF  SERVICE  TIME  DISTRIBUTIONS 
Eleanor  A.  Lester,  April  1973 
[M.Sc.  Thesis,  DCS.  1973] 

•  CSRG-28  PSYCHOLOGICAL  COMPLEXITY  OF  COMPUTER  PROGRAMS: 

AN  INITIAL  EXPERIMENT 
Larry  Weissman,  August  1973 

•  CSRG-27  STRUCTURED  SUBSETS  OF  THE  PL/I  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  October  1973 

•  CSRG-28  ON  REDUCED  MATRIX  REPRESENTATION  OF  LR(k) 

PARSER  TABLES 

Marc  Louis  Joliat,  October  1973 

[Ph.D.  Thesis.  EE  1973] 

•  CSRG-29  A  STUDENT  PROJECT  FOR  AN  OPEFIATING  SYSTEMS  COURSE 

B.  Czarnik  and  D.  Tsichritzis  (eds.),  November  1973 

•  CSRG-30  A  PSEUDO-MACHINE  FOR  CODE  GENERATION 

Henry  John  Pasko,  December  1973 
[M.Sc.  Thesis,  DCS  1973] 

•  CSRG-31  AN  ANNOTAED  BIBLIOGRAPHY  ON  COMPUTER  PROGIUUi  ENGINEERING 

J.D.  Gannon  (ed.).  Second  Edition,  March  1974 

•  CSRG-32  SCHEDULING  MULTIPLE  RESOURCE  COMPUTER  SYSTEMS 

E. D.  Lazowska,  May  1974 
[M.Sc.  Thesis,  DCS,  1974] 

•  CSRG-33  AN  EDUCATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 

F.  Lochovsky  and  D.  Tsichritzis,  May  1974 
[INFOR,  14  (3).  pp.270-278.  1976] 

•  CSRG-34  ALLOCATING  STORAGE  IN  HIERARCHICAL  DATA  BASES 

P.  Bernstein  and  D.  Tsichritzis,  May  1974 
[Information  Systems  Journal,  v.l,  pp. 133-140] 

•  CSRG-35  ON  IMPLEMENTATION  OF  RELATIONS 

D.  Tsichritzis,  May  1974 

•  CSRG-36  SDC  PL/I  COMPILERS 

D.B.  Wortman,  P.J.  Khaiat,  and  D.M.  Lasker,  August  1974 
[Software  Practice  and  Experience,  v.6,  n.3, 

July-Sept.  1976] 

•  CSRG-37  A  METHODOLOGY  FOR  STUDYING  THE  PSYCHOLOGICAL  COMPLEXHT 

OF  COMPUTER  PROGRAMS 
Laurence  M.  Weissman,  August  1974 
[Ph.D.  Thesis.  DCS.  1974) 
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*  CSRG-30  AN  INVESTIGATION  OF  A  NEW  METHOD  OF  CONSTRUCTING  SOFTWARE 

David  M.  Lasker,  SepUirnber  1974 
[M.Sc.  Thesis.  DCS.  1974] 

CSRG-39  AN  ALGEBRAIC  MODEL  FOR  STRING  PATTERNS 
Glenn  F.  Stewart.  September  1974 
[M.Sc.  Thesis.  DCS.  1974] 

*  CSRG-40  EDUCATIONAL  DATA  BASE  SYSTEM  USER’S  MANUAL 

J.  KlebanofT.  F.  Lochovsky,  A.  Rozitis,  and 

D.  Tsichritzis.  September  1974 

*  CSRG-41  NOTES  FROM  A  WORKSHOP  ON  THE  ATTAINMENT  OF 

RELIABLE  SOFTWARE 

David  B.  Wortman  (ed.),  September  1974 

*  CSRG-42  THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 

B.L.  Clark  and  F.J.B.  Ham,  September  1974 

*  CSRG-43  A  DATA  BASE  PROCESSOR 

E. A.  Ozkarahan,  S.A.  Schuster  and  K.C.  Smith. 

November  1974  [Proceedings  National  Computer 
Conference  1975,  v.44,  pp. 379-308] 

*  CSRG-44  MATCHING  PROGRAM  AND  DATA  REPRESENTATION  TO  A 

COMPUTING  ENVIRONMENT 
Eric  C.R.  Hehner,  Novemver  1974 
[Ph.D.  Thesis,  DCS,  1974] 

See  Computer,  Vol.9,  No. 9,  August  1976,  pp. 65-70. 

CSRG-45  THREE  APPROACHES  TO  RELIABLE  SOFTW^ARE;  LANGUAGE  DESIGN. 
DYADIC  SPECIFICATIONS,  COMPLEMENTARY  SEMANTICS 
J.E,  Donahue,  J.D.  Gannon.  J.V.  Guttag  and 
J.J.  Horning,  December  1974 

CSRG-48  THE  SYNTHESIS  OF  OPTIMAL  DECISION  TREES  FROM 
DECISION  TABLES 

Helmut  Schumacher,  December  1974 

[M.Sc.  Thesis,  DCS,  1974;  CACM,  v.l9,  n.6,  June  1976] 

*  CSRG-47  LANGUAGE  DESIGN  TO  ENHANCE  PROGRAMMING  RELIABILITY 

John  D.  Gannon,  January  1975 
[Ph.D.  Thesis.  DCS.  1975] 

*  CSRG-48  DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.M.  Turnbull,  January  1975 
[Ph.D.  Thesis.  EE.  1974] 

*  CSRG-49  A  NETWORK  FRAMEWORK  FOR  RELATIONAL  IMPLEMENTATION 

D.  Tsichritzis,  l^'chruary  1975  [in  Data  Base  Description, 

Dnngne  nnd  Nijssrn  (eds.),  North  Holland  Publishing  Co.] 


CSRG-50  A  UNIFIED  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 
AND  RELATIONS 

P.A.  Bernstein,  J.R.  Swenson  and  D.C,  Tsichritzis 
February  1975  [Proceedings  of  the  ACM  SIGMOD 
Conference,  1975] 

CSRG-51  ZETA:  A  PROTOTYPE  REIATIONAI.  DATA  BASE  MANAGEMENT  SYSTEM 
M.  Brodie  (ed).  February  1975  [Proceedings  Pacific  ACM 
Conference,  1975] 

CSRG-52  AUTOMATIC  GENERATION  OF  SYNTAX-REPAIRING  AND 
PARAGRAPHING  PARSERS 
David  T.  Barnard,  March  1975 
[M.Sc.  Thesis,  DCS,  1975] 

CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 
DATA  BASES 

J.H.  Gilles  Farley  and  Stewart  A.  Schuster,  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

J.V.  Guttag  (ed.).  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  May  1975 

CSRG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [Proceedings  Very  Large 
Data  Base  Conference,  1975] 

CSRG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 
Eric  C.R.  Hehner,  July  1975 

see  Acta  Informatica  Col.  10,  No.;5,  pp. 229-243,  1978 

CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Hans  Albrecht  Schmid  and  J.  Richard  Swenson, 

July  1975  [Proceedings  of  the  ACM  SIGMOD  Conference,  1975] 

CSRG-59  THE  SPECIFICATION  AND  APPLICATION  TO  PROGRAMMING 
OF  ABSTRACT  DATA  TYPES 
John  V.  Guttag,  September  1975 
[Ph.D.  Thesis,  DCS,  1975] 

CSRG-60  NORMALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 
RELATIONAL  DATA  BASE  MODEL 
Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS,  1975] 

CSRG-61  LSL:  A  LINK  AND  SELECTION  LANGUAGE 

D.  Tsichritzis,  November  1975  [Proceedings  ACM 
SIGMOD  Conference,  1970] 


CSRG-62 


CSRG-63 


CSRG-64 


CSRG-65 


CSRG-66 


CSRG-67 


CSRG-68 


CSRG-69 


CSRG-70 


CSRG-71 


CSRG-72 


COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  E.  Donahue.  November  1975 
[Ph.D.  Thesis,  DCS.  1975] 

AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING  HEURISTICS 
Lazio  Sugar,  December  1975 
[M.Sc.  Thesis.  DCS.  1975] 

A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

S.A.  Schuster.  E.A.  Ozkarahan,  and  K.C.  Smith. 

February  1976  [Proceedings  National  Computer 
Conference  1976.  v.45.  pp. 855-862] 

PERFORMANCE  EVALUATION  OF  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [ACM  Transactions  on  Database 
Systems,  v.  1,  n:4.  December  1976] 

EDITING  COMPUTER  ANIMATED  FILM 
Michael  D.  Tilson,  February  1976 
[M.Sc.  Thesis,  DCS,  1975] 

A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  R.  Cordy,  March  1976 
[M.Sc.  Thesis,  DCS,  1976] 

A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A  RELATIONAL 
ASSOCIATIVE  PROCESSOR 

L.  Kerschberg,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco, 

April  1978 


AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  and  D.  Thompson  (eds.),  Fourth  Edition, 
May  1976 


A  TAXONOMY  OF  DATA  MODELS 

L.  Kerschberg,  A.  Klug,  and  D.Tsichritzis,  May  1976 
[Proceedings  Very  Large  Data  Base  Conference,  1976] 


OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 
DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  K.C.  Sevcik,  May  1976 

[ACM  Transactions  of  Database  Systems,  v.2,  n.4,  December  1977] 


THE  RELATIONAL  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 
H.A.  Schmid  (od.),  P.A.  Bernstein  (ed.),  B.  Arlow, 

R.  Baker  and  S.  Pozgaj,  July  1970 
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CSRG-73  AN  AI.G0RITHM1C  APPROACH  TO  NORMALIZA'l’lON  OF 
RFI.ATIONAL  DATA  HASH  SCHEMAS 
P.A.  Bernstein  and  C.  Beeri,  September  1976 

•  CSRG-74  A  HIGH-LEVEL  MACHINE-ORIENTED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  S.A.  Schuster,  October  1976 

CSRG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE  PROGRAMMING 
CALCULUS 

Eric  C.R.  Hehner,  November  1976 
Acta  Informatica  to  appear  1979 

CSRG-76  SOFTW'ARE  HUT:  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J,  Horning  and  D.B.  Wortman,  November  1976 

[IEEE  Transactions  on  Software  Engineering,  v.SE-3,  n.4,  July  1977] 

CSRG-77  A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOUR 
G.  Scott  Graham.  January  1977 

CSRG-78  A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichritzis  (ed.),  February  1977 

CSRG-79  THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LAI.R 
PARSE  TABLE  CONSTRUCTOR 
David  H.  Thompson,  April  1977 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-80  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  (ed.).  Fifth  Edition,  May  1977 

CSRG-81  PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  BIBLIOGRAPHY 
FOR  IFIP  WORKING  GROUP  2.3 

Sol  J.  Greenspan  and  J.J.  Horning  (eds.),  First  Edition,  May  1977 
CSRG-82  NOTES  ON  EUCLID 

edited  by  W.  David  Elliot  and  David  T.  Beirnard,  August  1977 

CSRG-83  TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 

CSRG-B4  TOWARD  PROGRAM  ILLUSTRATION 

Edward  Yarwood,  September  1977 
[M.Sc.  Thesis,  DCS,  1974] 

CSRG-85  CHARACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME 

DISTRIBUTIONS  IN  QUEUEING  NETWORK  MODELS  OF  COMPUTER 
SYSTEMS 

Edward  D.  Lazowaka,  September  1977 
iPh.D.  Tliesia,  DCS.  1977] 
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CSRG-B6 


MEASUREMENTS  OF  COMIHJTER  SYSTEMS  FOR  QUEUEING 


NETWORK  MODELS 

Martin  0.  Kienzle,  October  1977 

[M.Sc.  Thesis,  DCS,  1977;  Proc.  Int.  Symp.  on  Modelling 
Evaluation  of  Computer  Systems,  Vienna,  1979] 


and  Performance 


CSRG-87  ’OLGA’  LANGUAGE  REFERENCE  MANUAL 

B.  Abourbih,  H.  Trickey,  D.M.  Lewis,  E,S.  Lee. 
P.I.P.  Boulton,  November  1977 


CSRG-88  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 
Brad  A.  Silverberg,  January  1978 
[M.Sc.  Thesis,  DCS.  1978] 

CSRG-89  ON  THE  IMPLEMENTATION  OF  RELATIONS:  A  KEY  TO  EFFICIENCY 
Joachim  W.  Schmidt,  January  1978 

CSRG-90  DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 
Frederick  H.  Lochovsky,  April  1978 
[Ph.D.  Thesis.  DCS.  1978] 

CSRG-91  SPECIFICATION  AND  VERIFICATION  OF  DATA  BASE 
SEMANTIC  INTEGRITY 
Michael  Lawrence  Brodie.  April  1978 
[Ph.D.  Thesis.  DCS.  1978] 

CSRG-92  STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP): 

AN  INTRODUCTION 

by  William  Buxton,  Guy  Fedorkow,  with  Ronald  Baecker, 

Gustav  Ciamaga,  Leslie  Mezei  and  K.C.  Smith,  June  1978 

CSRG-93  A  DEVICE-INDEPENDENT. GENERAL-PURPOSE  GRAPHICS  SYSTEM 
IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 
William  T.  Reeves.  August  1978 
[M.Sc.  Thesis,  DCS.  1976] 

CSRG-94  ON  THE  AXlOMA'nC  VERIFICATION  OF 
CONCURRENT  ALGORITHMS 
Christian  Lengauer,  August  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-95  PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1978 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis.  EE,  August  1978] 

CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 
TOOL  FOR  MUSIC  COMPOSITION 
Williuni  lluxtcrj 

iM.Sc.  Thesis.  eSRG,  October  1970] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES;  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  1.  Vanek,  February  1979 

CSRG-100  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 

CSRG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.).  May  1979 

CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.Pt.  Hehner,  May  1979 

CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  July  1979 

CSRG-105  A  LANGUAGE  FACILIiY'  FOR  DESIGNING  INTERACTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos,  Philip  A.  Bernstein,  Harry  K.T.  Wong, 
July  1979 

CSRG-106  ON  APPROXIMATE  SOLUTION  TECHNIQUES  FOR 

QUEUEING  NETWORK  MODELS  OF  COMPUTER  SYSTEMS 
Satish  Kumar  Tripathi,  July  1979 

CSRG-107  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  K.  Tsotsos,  John  Mylopoulos,  H.  Dominic  Cowey 
Steven  W.  Zuckcr,  DCS,  June  1979 

CSRG-108  DIALOGUE  ORGANIZATION  AND  STRUCTURE  FOR 
INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thesis,  DCS,  1900] 

CSRG-109  A  UNIFYING  MODEL  OF  PHYSICAL  DATABASES 
D.S.  Batory,  C.C.  Gotlieb,  April  1980 

CSRG-110  OPTIMAL  FILE  DESIGNS  AND  REORGANIZATION  POINTS 
D.S.  Batory,  April  1980 

CSRG-111  A  PANACHE  OF  DBMS  IDEAS  HI 
D.  Tsiehritzis  (ed.).  April  1980 
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CSRG-1 12  TOPICS  IN  PSN  -  11:  EXCEPTIONAL  CONDITION 

HANDLING  IN  PSN:  REPRESENTING  PROGRAMS  IN  PSN; 
CONTENTS  IN  PSN 

Yves  LespereLtice,  Byran  M.  Kraimer,  Peter  F.  Schneider 
April,  1980 

CSRG-113  SYSTEM-ORIENTED  MACRO-SCHEDULING 
C.C.  Gotlieb  ondA.  Schonbach 
May  1900 

CSRG-1 14  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDLNG 
John  Konstantine  Tsotsos 
[Ph-D.  Thesis,  DCS,  June  1980] 

CSRG-1 15  SPECTFICATION  OF  CONCURRENT  EUCLID 
James  R.  Cordy  and  Richard  C.  Holt 
July  1980  ; 

CSRG-116  THE  REPRESENTATION  OF  PROGRAMS  IN  THE 

PROCEDURAL  SEMANTIC  NETWORK  FORMALISM 

Bryan  M.  Krauner 
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